General hints:
(1) How to tell an SNMPv2 MIB from an SNMPv1 MIB.
After the IMPORTS section, an SNMPv2 MIB starts with a MODULE-IDENTITY
clause, while an SNMPv1 MIB does not. The MODULE-IDENTITY clause does
not exist in SNMPv1. That's how you tell the difference between an
SNMPv1 and an SNMPv2 MIB.
(2) Look at the IMPORTS section in the MIB before you try to load it.
All MIBs start with an IMPORTS section which tells you what other MIBs
you need to load them properly. Generally speaking, you do not need to
load any of the early RFCs, the ones with numbers lower than 1500
because those constructs are already built-in to the
NetView loaders and
browsers. The newer RFC's, the ones with numbers higher than 1500 you
will almost certainly need. But the number one use for the IMPORTS clause
is so that you know what other VENDOR MIBs need to be loaded in order to
resolve what's in the one you have. If you don't get the vendor MIBs
mentioned in the IMPORTS section and load them first, then you will
almost certainly get a "left over nodes" warning message such as the one
you posted. That's the typical cause of that message, that the MIB
databases does not have the anchor point for all of the elements that
some other MIB requires. Another reason might be that the basic
definition of the anchor point has a problem, but usually the issue is a
missing pre-req. These latter syntax problems will never be in RFC's,
they will be in vendor MIBs.
Specific suggestions:
How does this specifically apply to your situation? The "left over
nodes" message is only a warning. That means that the MIB you tried to
load in fact did load. But you were warned that not all of it could be
resolved. If you did not immediately unload it, then, from that point
on however, any other MIB you try to load will get the same warning
message because the loader produces it while incorporating the new MIB
into the entire MIB database. That's why you see the high line number
(185827). The problem is already in the MIB database, and not in the
MIB you are trying to load; in this case the TOKEN-RING-RMON-MIB.txt,
but in some previous MIB you already loaded. How can you find out what
MIB that is?
Each MIB loader has both a text file and a binary file. The SNMPv1
loader, xnmloadmib, has /usr/OV/conf/snmpmib (text file) and
/usr/OV/conf/snmpmib.bin (binary file). The SNMPv1/SNMPv2 loader,
xnmloadmib2, /usr/OV/conf/snmpv2mib (text file) and
/usr/OV/conf/snmpv2mib.bin (binary file). To find what MIB is causing
your error, browse the text file for that loader and find out what MIB
contains the first clause in the warning message. Locate the definition
for
Left-over node rptrInfoResetEvent ::= { 5 } (0)
and then scroll up until you find the keyword BEGIN that indicates the
start of the MIB. If you unload that MIB, then your warning messages
should go away. But this requires care because if you have been
ignoring this message and have loaded many new MIBs already, you may
have introduced new dependencies that will cause new warnings when you
unload your problem MIB. Compiling MIBs is very much like compiling a
program. It is best to resolve the first error you come to rather than
to try to continue.
Now based upon what I know about the native
NetView MIB loaders, the
fact that this error message has this peculiar value at the end of each
line, "(0)", indicates to me that the MIB which contains it has a syntax
problem that our loader cannot resolve. Would that be the entityXMIB?
You can try using the process I just outlined to determine that and
remove it from the database.
Finally, I have to say once again that MIBs are like program source
code, and each MIB compiler has different syntactical requirements
depending on how they are built. Just as some program compilers are
more picky about spaces and punctuation, so also some MIB compilers are
pickier than others about the same things. And some vendors don't
compile their MIBs at all before shipping them. They just think they
have done it right. So there are no automatic tools to correct MIB
syntax. What you need is experience. Which is why a call to IBM
Support is in order when you cannot figure it out for yourself. You can
learn from them.
James Shanks
--
JaneCurry - 04 Dec 2004