Source: https://agentpp.com/services/mibdesign.html
Timestamp: 2019-04-21 10:24:47+00:00

Document:
This page contains descriptions, explanations, and solutions for the top 10 MIB Design errors. These issues have been collected over years from support questions and consulting projects. Soon it turned out, that a few misunderstandings of the Structure of Management Information RFCs produce a majority of over 80% of the syntax errors. This page is an attempt to help MIB authors to identify and avoid these, unfortunately very common, errors in order to increase interoperability and usability of SNMP based solutions.
Why do so many (enterprise) MIB modules contain syntax errors and other design flaws? The main reason is probably, a lack of good MIB design tools (editors and compilers) in the early years of SNMP. MIB authors relied on inaccurate implementations of MIB parsers that were not developed to do strict syntax and semantic checking but rather designed to be error-forgiving. With an increasing number of available SNMP tools, interoperability problems also increased caused by the diversity of different error checking levels and capabilities.
Another reason for many interoperability issues is likely to be the “bad habit” of many MIB compilers and tools to provide customizable error reporting levels allowing users to disable reporting of errors/warnings although these errors - or even more worse - warnings report SMI standard violations.
RFC 2578 §3 requires that every SMIv2 MIB module starts with a MODULE-IDENTITY construct (immediately following the IMPORTS clause). Because the Structure of Management Information (SMI) lacks explicit versioning, the absence or presence of the MODULE-IDENTITY is the only usable indication for a SMI parser whether a module is written for SMI version 1 (MODULE-IDENTITY is absent) or version 2 (MODULE-IDENTITY is present). Probably caused by some MIB compilers that cannot handle object identifier forward referencing correctly, some MIB authors do not place the MODULE-IDENTITY immediately following the IMPORTS clause as shown be the below example.
Note: All comments (green text) in the above example are optional and need not to be present. In fact some old MIB compilers have problems correctly recognize the end of comments. The end of a comment is either marked by two consecutive hyphens (‘--’) or the end of the line. The first should be avoided for maximum interoperability.
Descriptors, i.e., object names, enumeration labels, have to start with a lower case letter. MIB module names and type names, i.e., names of TEXTUAL-CONVENTIONs and SEQUENCEs, have to start with an upper case letter. For more details see RFC 2578 §3.1.
Note: In the above example, only the red marked portions are invalid. The object names for the OBJECT-TYPE definitions have been chosen to have a common prefix as recommended by RFC 2578, that is unique (by best effort) across other MIB modules. For this example, the common prefix is “mibdesignInvalidSequence”.
* The hyphen (‘-’) is only allowed in MIB module names and for SMIv1 descriptors and identifiers (e.g. enumeration labels). In SMIv2, hyphens are only allowed if the MIB module was converted from SMIv1 (which is hard to prove by a MIB compile, see also SMIv2 Design Team Issues). Hyphens in enumeration labels are not allowed in SMIv2. In any case a descriptor or identifier must not end with a hyphen. One reason for the latter, might be easier mapping of enumeration labels to programming languages, where the hyphen is commonly interpreted as minus sign.
Note: The second line above was marked by MIB Designer because it expected a range restriction but found “MAX-ACCESS”.
RFC 2580 §3.1 and §4.1 respectively require that each accessible OBJECT-TYPE definition must be contained in at least one OBJECT-GROUP definition and every NOTIFICATION-TYPE definition must be contained in at least one NOTIFICATION-GROUP definition. These requirements assure that every object of a MIB module can referenced by a compliance statement. This kind of error is usually introduced in a MIB module when a new object is added and the MIB author forgets to add it to a group. MIB Designer offers the option to import a MIB module with a lenient MIB compiler mode and then adding the missing object group entries by using a shuffle dialog that shows the unassigned OBJECT-TYPEs or NOTIFICATION-TYPEs respectively.
Z the character Z, which denotes GMT, must always be present.
There cannot be associated any parsable information to an ASN.1 type assignment. In the above example important information included in the description clause would be lost.
RFC 2576 §2.1.1 demands that all ASN.1 type assignments should be converted to TEXTUAL-CONVENTION definitions in a SMIv2 MIB module.
Although MIB Designer can resolve such derivation chains even across several MIB modules, some MIB compilers cannot which could cause interoperability issues. For example, there are MIB compilers that would not recognize that AppnTOSPrecedence in the above example has inherited the DISPLAY-HINT “255a” from DisplayString.
RFC 2578 §7.1.12 requires that for every columnar object of a conceptual table definition a corresponding entry is present in the SEQUENCE clause defining the syntax of the conceptual row of the table. The entries in the SEQUENCE clause must appear in the lexicographic order of the columnar objects (thus ordered by their last sub-identifier). Normally this is not problematic, since most MIB authors order the columns by the last sub-identifier. But if this is not the case, for example if columns have been added by a new revision of a MIB module, then attention has to paid on the order of the elements in the corresponding SEQUENCE clause.
The following example illustrates an error caused by wrong ordering of the SEQUENCE elements. To correct the error, one would have to swap mibdesignDontsInvalidSeqCol3 and mibdesignDontsInvalidSeqCol2 entries as indicated by the red boxes. Changing the sub-identifiers of those columns is not allowed by a revision, because this would change the behavior of the table on the wire.
RFC 2578 §3 explicitly forbids the usage of SMIv1 macro definitions in SMIv2 modules. The usage of SMIv2 constructs like TEXTUAL-CONVENTION is forbidden in SMIv1 too. These kind of errors often occur when manually converting a module from from one version to another and when the MIB parser/compiler used to check the conversion result does not properly distinguish between SMIv1 and SMIv2. MIB Designer clearly distinguishes between SMIv1 and SMIv2 and will reliably report such errors. In addition it provides automatic conversion from SMIv2 to SMIv1 (see RFC 2576 for situations where an automatic conversion is not completely possible). Any new SNMP MIB module should be written in SMIv2 (the corresponding RFCs 2578, 2579, and 2580 are STANDARD). That’s why MIB Designer focusses on SMIv2 and does not allow to write new MIB modules in SMIv1. Nevertheless, MIB Designer warns MIB author’s when defining a NOTIFICATION-TYPE that is not backward-compatible with SMIv1 and SNMPv1 (see RFC 2576 §3 for details), because the NOTIFICATION-TYPE’s second to last sub-identifier is not zero. Although RFC 2576 defines a mapping for such notifications to SNMPv1 traps, it is wise to avoid such notification definitions for better interoperability.

References: §3
 §3
 §3
 §4
 §2
 §7
 §3
 §3