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

Compare with Current View Page History

Version 1 Current »

How to resolve MIB dependencies (load order) with custom MIBs.
The following symptoms in the Uptime Infrastructure Monitor 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 <span style="color: #0052cc">iReasoning MIB Browser</span>. 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.
Unable to render embedded object: File (worddav48b349cb6b49ea9a5426b008b97e0c8e.png) not found. <span style="color: #333333"><strong>Info</strong></span>
<span style="color: #333333">You may see some warnings in the thirdparty.log file similar to the messages below but these are not cause for concern:</span>
<span style="color: #333333"><em>2012-06-12</em></span> <span style="color: #333333"><em>14:35:35,699</em></span> <span style="color: #333333"><em>ERROR</em></span> <span style="color: #333333"><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="65a6ecc5-29b5-450d-b196-d701b845129a"><ac:plain-text-body><![CDATA[[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 /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 /mibs/ directory so that Uptime Infrastructure Monitor 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 Uptime Infrastructure Monitor 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