Contact Us

pdf icon small Printable Version

Although there are hundreds of IETF standard track MIBs, developers often have a need for a MIB object that is not defined in any of the standard MIBs. Developers then create a private or enterprise MIB to add the missing object they need and include several others that are useful for their application.

Over the years, InterWorking Labs has kept a tally of the most common MIB creation errors -- fundamental mistakes that are made in the development of MIBs. Although many management products will either ignore or work around these errors, custom applications will fail. Many of these custom applications are in use in the largest networks, so MIB errors in the private MIB you created for your SNMP agent in your device will show up with your most important customers when they use their applications to manage and monitor your device!

What are these MIB errors that we see time and time again?

(1) Incorrect format for comments.

In SNMP, two adjacent hyphens (--) start a comment. A comment can be ended by a line terminator or another set of two adjacent hyphens. When lines wrap, or when hyphens are used to separate text or when hyphens are used for an ASCII drawing, it is easy to lose track and introduce syntax errors. The best solution is to use a line terminator for the end of a comment, and not another set of hyphens.

(2) Object names must start with a lower case letter, not a hyphen, number, or other character.

(3) Using a hyphen in the name of an identifier in SMIv2.

It was okay in SMIv1, but the rules changed for SMIv2.

(4) Mixing SMIv1 and SMIv2 MIB rules in a MIB.

This usually happens when a MIB designer is enhancing a MIB based on SMIv1 and adds SMIv2 constructs, thus mixing the two structures. A MIB cannot comply with both SMIv1 and SMIv2 at the same time.

For example, if you are using SMIv2, then all the STATUS values that say "mandatory" should be changed to "current". The type Counter is changed to Counter32 in SMIv2, and the type Gauge is Gauge32.

(5) Using the incorrect format for the date and time object: ExtUTCTime

Allowable formats are: YYMMDDHHMMZ or YYYYMMDDHHMMZ The Z at the end denotes GMT. See RFC 2578 for more explanation.

(6) Using underscores in object identifiers in either SMIv1 or SMIv2.

Underscores are prohibited for object names in both structures.

SilverCreek's MIB compiler flags and reports many of these errors, allowing your MIB to finish compiling. We agree that many of the rules are very picky, but some of them will introduce interoperability problems, so we point them out for your benefit.

Not sure what you need?