Okay, I really like standards – preferably open standards. And I really like SNMP, although sometimes I think that having the word “Simple” in its name was a mistake.
I love simplicity. I think for all of OpenNMS’s power, it is at heart a simple product. But some vendors confuse simplicity with sloppiness, and it causes me no end of grief.
For example, a client called me with the news that he was unable to get OpenNMS to discover one of his devices for data collection. Digging into the logs we find that there is a null pointer exception when it is trying to retrieve the ifSpeed from the device. Using UCD’s snmpwalk you get:
snmpwalk -c public 10.1.1.1 ifTable.ifEntry.ifSpeed interfaces.ifTable.ifEntry.ifSpeed.1 = Wrong Type (should be Gauge32 or Unsigned32): 160000000 interfaces.ifTable.ifEntry.ifSpeed.10001 = Wrong Type (should be Gauge32 or Unsigned32): 160000000 interfaces.ifTable.ifEntry.ifSpeed.40001 = Gauge32: 38400 interfaces.ifTable.ifEntry.ifSpeed.40002 = Gauge32: 38400 interfaces.ifTable.ifEntry.ifSpeed.40005 = Gauge32: 44000000 interfaces.ifTable.ifEntry.ifSpeed.50001 = Gauge32: 10000000 interfaces.ifTable.ifEntry.ifSpeed.50002 = Gauge32: 10000000 interfaces.ifTable.ifEntry.ifSpeed.50003 = Gauge32: 38400
Now, how can you get part of the MIB right, and then blow it on the other part? I assume it is because of the high value, but it should still fit into 32 bits – 2^32 ~ 4 billion (unless my math is wrong).
Luckily, OpenNMS is open, so the source code change to ignore the wrong numbers was pretty simple to do.
A much harder fix will be for the problem where the SNMP agent does not respond correctly to snmpgetbulk requests. Ain’t it grand to be able to work around the issues, though?