The following symptom=
s in the Uptime Infrastructure Monitor MIBBrowser are signs that there is a=
n issue with the order that custom MIBs are being loaded from the <uptim=
e_dir>/mibs/ directory:
- MIB Tree is not fully =
populated compared to the iReasoning MIB Browser.
- Invalid OID errors rec=
eived when trying to select an OID from the MIB itself.
To verify that this i=
s the issue (and to identify the offending MIB), look in the thirdparty.log file located in the <upt=
ime_dir>/logs directory and look for errors such as:
=
2012-06-1=
1 11:35:21,833 ERROR [Webserver-32 - /uptime/snm=
p/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 fail=
ed to load because they were missing some of their imports.
To resolve the errors (MIB loaded from reader contains unkn=
own 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:
IMPORTS
OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-=
IDENTITY, enterprises
FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC
Counter64, Unsigned32 FROM SNMPv2-SMI=
span>
Counter FROM RFC1155-SMI
ibDHCPOne, IbString, IbIpAddr FROM IB-S=
MI-MIB;
In this example, =
;IB-SMI-MIB is a n=
on-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 hav=
e identified which MIB contains the missing import values, we need to re-na=
me the file in the <uptime_dir>/mibs/ directory so that Uptime Infras=
tructure 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&nb=
sp;originally named:
IB-DHCPONE-MIB.mib
IB-SMI-MIB.mib
Re-named to:
03000-IB-SMI-MIB.mib<=
/span>
03001-IB-DHCPONE-MIB.=
mib
After re-naming=
the files, restart the uptime_core/data collector services on the monitori=
ng station, which will cause Uptime Infrastructure Monitor to clear it's ca=
ched MIBs from memory. Then=
set up a new SNMP Poller monitor, and clic=
k the Add OID button, which will reload the MIBs into memory in the new ord=
er. Once these are loaded into memory again, you should also now be a=
ble to fully drill down to the OID in question in the MIB browser. Ch=
ecking the thirdparty.log file again should also no longer have errors abou=
t missing imports for the MIB.