How to resolve MIB dependencies (load order) with custom MIBs.
The following symptoms in the up.time MIBBrowser are signs that there is an issue with the order that custom MIBs are being loaded from the <uptime_dir>/mibs/ directory:
- MIB Tree is not fully populated compared to the iReasoning MIB Browser.
- Invalid OID errors received when trying to select an OID from the MIB itself.
To verify that this is the issue (and to identify the offending MIB), look in the thirdparty.log file located in the <uptime_dir>/logs directory and look for errors such as:
2012-06-11 11:35:21,833 ERROR [Webserver-32 - /uptime/snmp/getMibTree] (Log4jImpl:36) - MIB loaded from reader contains unknown mib imports: ibDHCPOne.
The corresponding MIB needs to be loaded beforehand or it should be in the same directory as current MIB
2012-06-11 11:35:21,852 ERROR [Webserver-32 - /uptime/snmp/getMibTree] (Log4jImpl:36) - MIB loaded from reader contains unknown mib imports: ibDHCPServ.
The sample errors listed above indicate that the ibDCHPOne & ibDHCPServ MIBs failed to load because they were missing some of their imports.
You may see some warnings in the thirdparty.log file similar to the messages below but these are not cause for concern:
2012-06-12 14:35:35,699 ERROR [Webserver-23 - /uptime/snmp/getMibTree] (Log4jImpl:36) - Unknown snmp data type: [APPLICATION.
The corresponding MIB need to be placed in the same directory or loaded beforehand.
To resolve the errors (MIB loaded from reader contains unknown mib imports), open the MIB that failed to load from the <uptime_dir>/mibs/ directory and look at the imports section near the top. For example, from the ibDHCPOne sample in the error above:
OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, enterprises
TEXTUAL-CONVENTION FROM SNMPv2-TC
Counter64, Unsigned32 FROM SNMPv2-SMI
Counter FROM RFC1155-SMI
ibDHCPOne, IbString, IbIpAddr FROM IB-SMI-MIB;
In this example, IB-SMI-MIB is a non-bundled MIB and the source of the import issues because it was not properly loaded before the ibDHCPOne tried to import values from it.
Now that we have identified which MIB contains the missing import values, we need to re-name the file in the <uptime_dir>/mibs/ directory so that up.time will load that one before the others. The MIB files are loaded in alphanumeric order (i.e. 0 - 9 then A - Z then a - z). So, using the examples above, they were originally named:
After re-naming the files, restart the uptime_core/data collector services on the monitoring station, which will cause up.time to clear it's cached MIBs from memory. Then set up a new SNMP Poller monitor, and click the Add OID button, which will reload the MIBs into memory in the new order. Once these are loaded into memory again, you should also now be able to fully drill down to the OID in question in the MIB browser. Checking the thirdparty.log file again should also no longer have errors about missing imports for the MIB.