5 Common MIB Issues
4) Typos in the MIB
Bad syntax in a MIB file can create errors when compiling. Exactly how much goes wrong will vary based upon the compiler that your are using. Some are less forgiving than others. Although typos in the MIB can take many forms, one of the most common is the incorrectly escaped file comment.
File comments in MIBs are offset from the rest of the file by double hyphens (--) and generally continue until the end of the line. An important exception is that comments can be ended by a second pair of hyphens on the same line. Any text on the same line after this second pair of hyphens will be parsed by the compiler as if it were normal MIB code, causing an error.
IMPORTS--This comment is correctly inserted
DisplayString--As is this one--BUT THIS ONE WILL CAUSE AN ERROR!
As you can see in the above example, the first comment does not create a problem, nor does the second. The third, however, appears outside of the second double hyphen (--) on the same line and is considered part of the MIB code during compiling. The compiler will not know how to handle it, and an error will be generated. Look for this and other typos in your MIB files
If you'd like additional information about MIB files to identify other kinds of typos, please read Demystifying the MIB, another white paper available at no cost from DPS Telecom
5) "Pre-compiled" MIBs
Using "pre-compiled" MIBs is not always the best choice. MIBs that were compiled for a target platform other than your manager can create a range of potential problems. The MIB files you use should be text-readable before you compile them to your manager.
Don't Forget the Obvious
You don't want to spend any unnecessary time searching for complex problems, so be sure to check for these simple and "obvious" ones during
- Is your remote device sending traps to the IP address of the target manager?
- Is your remote device provisioned to send traps?
- Is your IP addressing, including subnet and gateway, set up correctly on the remote device?
- Is your IP routing configuration (DNS or static) correct?
Get More From SNMP with Sets and Gets
Issuing Set and Get messages from your SNMP manager can enhance your monitoring and give you more control over your remote sites.
A Set message allows the manager to request a change be made to the value of a specific variable. The agent will then respond with a SetResponse message indicating the change has been made or an error indication as to why the change cannot be made. To be set, a variable must have read-writable characteristics defined in the MIB. Errors commonly occur when attempting to set a variable that has read-only attributes.
The Get and GetNext messages allow the SNMP manager to request information for a specific variable. The agent, upon receiving a Get or GetNext message, will issue a GetResponse message to the manager with either the information requested or an error indication as to why the request cannot be processed.