Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

Note that 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.
 
The sample errors listed above indicate that the ibDCHPOne & ibDHCPServ  MIBs failed to load because they were missing some of their imports.

To resolve this issue, 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:
 
IMPORTS
   OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, enterprises
        FROM SNMPv2-SMI
   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:

IB-DHCPONE-MIB.mib
IB-SMI-MIB.mib

Re-named to:

03000-IB-SMI-MIB.mib
03001-IB-DHCPONE-MIB.mib

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.
  • No labels