MIB concepts and design

All SNMP MIB modules that are defined for use by a specific device comprise the MIB for that device. The term MIB is often used to describe a single module definition but this is technically incorrect. In fact, the MIB is the combination of all of the modules used for managing a specific device, whether the device relates to hardware or software. Therefore, the more precise name for each module defined by a vendor, or in an RFC, is SNMP MIB module.

All MIB modules are eventually extensions of the root module. All released MIB modules, from individual vendors, extend from the enterprises object defined in RFC1155-SMI. Therefore, all SNMP agents must support RFC1155, and all MIB modules are extensions of RFC1155.

Structure of Management Information (SMI)

To make the SNMP management information base (MIB) extensible, related items are arranged into MIB modules that form a structured hierarchy. Each MIB module is defined inside the following construct:

ModuleName DEFINITIONS ::= BEGIN END

The BEGIN and END tags in the module enable several modules to be defined within a single text file. MIB compilers should be able to handle any number of modules defined in a single file, but should not require it.

There are conventions for every defined object within the module. For example, a module name must begin with an uppercase alphabetic character and contain only letters, numbers, hyphens (-), or underscores (_). An object name must start with a lowercase alphabetic character and must only contain letters, numbers, hyphens, or underscores. Comments in MIB modules are represented by two consecutive hyphens (--) and any text following this symbol, on any line, can be ignored.

The modular, easily extensible design of MIBs makes them able to support any new functionality or device by adding an additional module. When a module is written as an extension of another module, it will include an IMPORTS section, located below the DEFINITIONS line. The IMPORTS section defines the objects required by modules higher in the MIB hierarchy and the modules in which they in turn are defined.

The following definition is from RFC1157 and indicates several objects which are imported from RFC1155. This section can be viewed as analogous to the include statement in a programming language such as C or Perl, or in a Netcool rules file. Additionally, in order to understand the objects in the current MIB module (RFC1157-SNMP) you must also be aware of the objects in the previous MIB module (RFC1155-SMI). 
RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, 
IpAddress, TimeTicks FROM RFC1155-SMI;

Typographical errors are easily made when specifying imported MIB names. For example, RFC1212 might be referenced as a MIB module instead of the correct name, RFC-1212. If parsing errors are highlighted by MIB Manager, you must check the IMPORTS section to confirm that the MIB modules are correctly named. Some MIB modules also contain an EXPORTS section (which also ends with a semicolon). This section informs the reader that the MIB author expects other MIB modules to use the same specified objects. For our purposes, this section is irrelevant and can be ignored.

Defined data types

SNMP MIB modules are defined in a format known as ASN.13 (Abstract Syntax Notation 1). SNMP, however, only uses a portion of ASN.14. ASN.1 is defined in ITU-T X.208 and in ISO 8824. The portions of ASN.1 that apply to SNMP are defined in RFC1155. RFC1155 defines the following valid SNMP data types:

  • Primitive types: INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL
  • Constructor types: SEQUENCE, SEQUENCE OF
  • Defined types: NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, Opaque

A defined type is the mechanism used to specify a particular format for primitive or constructor types. MIB authors can define additional types using the TEXTUAL-CONVENTION construct.

DisplayString is a good example of a defined type. In the SNMPv2-SMI-v1 MIB module, the v1 version of DisplayString has the following definition:
DisplayString ::= OCTET STRING (0..255)
In the SNMPv2-TC MIB module, the v2 version of DisplayString has the following definition: 
DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION 
"Represents textual information taken from the NVT ASCII character set, as defined 
in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire 
specifies: - the use of character codes 0-127 (decimal) - the graphics characters 
(32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the 
special meanings specified in RFC 854 - the other 25 codes have no standard 
interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means 
carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on 
the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. 
(Note that this also means that a string may end with either 'CR LF' or 'CR NUL', 
but not with CR.) Any object defined using this syntax may not exceed 255 characters
 in length." SYNTAX OCTET STRING (SIZE (0..255))
The example above shows that a DisplayString is an OCTET STRING of 0 to 255 characters in length. Note that each OBJECT DESCRIPTOR that corresponds to an object type in an internet-standard MIB must be a unique, mnemonic, printable string.

Defining objects

A common mistake made when writing MIB modules is to create an object name that is not unique. It is claimed that the RFC1155 statement means that only objects within a single MIB module must be unique. As previously discussed, the MIB is the complete set of modules which, when combined, are used to manage a particular device. Therefore, all objects defined in any MIB module must be unique, not only in its own module, but also in any other object name in any imported modules, and any modules that those modules may import. A common mechanism for ensuring that object names are unique is to pre-pend all module names with the company's ticker symbol or abbreviated company name.

When objects are defined they are mapped into a numerical hierarchy which resembles a spanning tree. Each time an object is defined, it is defined as a leaf of a parent object. The following three root objects are defined in the SNMP MIB tree:

  • ccitt (root node zero)
  • iso (root node 1)
  • joint-iso-ccitt (root node 2)
All other nodes in the MIB tree are children of one of these three root nodes. For example, RFC1155-SMI defines the following objects: 
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::=
 { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER
 ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT 
IDENTIFIER ::= { private 1 }

These definitions indicate the object name, the associated object types, each object's parent name (or ordered list of parents), and the leaf number of this child to that parent (or parents). Graphically, these items take on a hierarchical form.

You move through the MIB tree view by expanding and collapsing nodes within the MIB tree. The top level branches of the MIB tree contain the names of the MIB modules, and contained within each MIB module branch are the other elements which comprise the MIB. As additional modules are added to the MIB, additional objects are added to the MIB tree. Each object can be referred to either by its object name or by its object identifier (OID). The most accurate method is to refer to its OID. Its OID is defined as its number, and each of its ancestor's numbers continuing back to the root node, concatenated together with a period (.) separating each. The OID for the enterprises object (node or leaf) is 1.3.6.1.4.1.

Many vendors do not ensure that their object names are universally unique, therefore it is possible for two vendors to have an object sharing the same name. This makes the use of the object name to identify an object a little ambiguous.