Geek alert: SNMP configuration

[unixronin]

I have an odd problem, which can be seen here on my MRTG monitoring page.  You'll notice there is heavy sustained bandwidth from hme0 on minbar.babcom.com and ge1 on vorlon.babcom.com, on the order of 30 megabits per second.  That is backup traffic, and it's going to hme0 on babylon5.babcom.com.

So ... where is it on babylon5's graph?  It's just flat not there.

As far as I can tell, the problem here is that SNMP is deluded about the speed of that interface.  The interface is a 3Com 3C905C-TX, running full-duplex 100-megabit, but SNMP stubbornly thinks it's a 10-megabit interface:

interfaces.ifTable.ifEntry.ifIndex.2 = 2
interfaces.ifTable.ifEntry.ifDescr.2 = eth0
interfaces.ifTable.ifEntry.ifType.2 = ethernetCsmacd(6)
interfaces.ifTable.ifEntry.ifMtu.2 = 1500
interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge32: 10000000
interfaces.ifTable.ifEntry.ifPhysAddress.2 = 0:50:4:b:d1:56

I'm speculating that when mrtg receives data indicating 30 megabits per second being transferred over an interface that it KNOWS is only capable of 10 megabits per second, it's throwing the data away because it's, like, obviously wrong, right?

Here's what happens when I try to dsabuse snmpd of this incorrect notion about eth0's speed:

babylon5:root:/opt/bacula/etc:35 # snmpset babylon5 [writecommunity] interfaces.ifTable.ifEntry.ifSpeed.2 = 100000000
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: interfaces.ifTable.ifEntry.ifSpeed.2

OK, can't set it this way, the MIB doesn't recognize the variable, so I can't use =, I have to explicitly specify the variable type:

babylon5:root:/opt/bacula/etc:36 # snmpset babylon5 [writecommunity] interfaces.ifTable.ifEntry.ifSpeed.2 i 100000000
interfaces.ifTable.ifEntry.ifSpeed.2: Bad variable type (Type of attribute is Gauge32, not INTEGER)

Bummer, SNMP says it's a Guage32, and I have no variable type to set that.

OK, so maybe I can do it by changing the type of the interface from 6 (ethernetCsmacd) to 69 (Full Duplex Fast Ethernet):

babylon5:root:/opt/bacula/etc:39 # snmpset babylon5 [writecommunity] interfaces.ifTable.ifEntry.ifType.2 = 69
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: interfaces.ifTable.ifEntry.ifType.2
babylon5:root:/opt/bacula/etc:40 # snmpset babylon5 [writecommunity] interfaces.ifTable.ifEntry.ifType.2 i 69
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: interfaces.ifTable.ifEntry.ifType.2

So ... can anyone tell me how I educate snmpd about eth0's actual capabilities?

---

Update: Found the problem!

There's a directive that can be inserted into the snmpd.conf file to override an incorrectly-detected interface rate.  Simple enough, huh?  But snmpd was ignoring it.  Turns out that the documented syntax of that directive in the man page is WRONG.  So the directive was wrong .... and rather than reporting the error, snmpd was just silently ignoring it.  (Bastard!)

The directive is now fixed, snmpd is reporting the correct interface speed, and MRTG is now showing all the traffic it should be showing.

Comments

[robbat2.livejournal.com]

I don't know what snmpd implementation, but with net-snmp, you can use type 'u' for setting Gauge32 variables.

However I think that interfaces.* might be read-only data, so you may need to fix where snmpd gets it's data from.

[unixronin.livejournal.com]

Ah, yeah, I finally found the source MIB file and it appears all the if parameter fields are read-only. The key seems to be to convince snmpd that eth0 is an IANA type 69 (100fdx) instead of an IANA type 6 (10hdx); I just can't figure out, thus far, how to accomplish this.

[unixronin.livejournal.com]

hmmm..... actually, no, that seems not to be it, because all the other assorted 100HDX and 1000HDX interfaces also come up as type 6, and their speeds are correct.

So we're back to educating snmpd about the interface's correct speed.

Aha!

[unixronin.livejournal.com]

problem solved. (See the update.) It turned out to be partly a frelling documentation problem.

[claire.livejournal.com]

Hee! Sometimes reading the man pages is worse than not reading them at all.