What Does a MIB Look Like?

The Management Information Base (MIB) is a key component of the Simple Network Management Protocol (SNMP). More specifically, a MIB is a group of managed objects within a network. This local database is compiled to the SNMP manager and contains knowledge relevant to network management.

Both the SNMP manager and agent utilize this database. The manager uses the MIB as a "reference" to know traps, or messages, sent from agents within the network.

The MIB is essentially a codebook that translates these numerical strings into human-readable text. Elements defined in the SNMP MIB can be very broad like all objects created by private businesses, or very specific, like a particular trap message generated by a certain alarm point on an RTU.

A MIB is organized into a tree. The elements defined in the MIB syntax can be extremely broad (for example, all objects created by private businesses) or they can be extremely specific (like a particular Trap message generated by a specific alarm point on an RTU. Individual objects in the MIB have an object identifier (OID), which the manager uses to determine the values from those single devices. These objects can be specific alarm points, with one representing an alarm, and another representing a clear.

If an object does not have an identifier within an SNMP MIB, it does not exist to your SNMP manager. For example, if an SNMP RTU has a built-in component to monitor temperature, but the temp sensor is not listed in the MIB file, the RTU will be unable to send and receive traps with temperature data.

For example, here are the first few lines of the standard DPS Telecom MIB file.

  DisplayString
 FROM RFC1213-MIB
 OBJECT-TYPE
 FROM RFC-1212
 enterprises
 FROM RFC1155-SMI;
 dpsInc OBJECT IDENTIFIER ::= {enterprises 2682}
 dpsAlarmControl OBJECT IDENTIFIER ::= {dpsInc 1}
 tmonXM OBJECT IDENTIFIER ::= {dpsAlarmControl 1}
 tmonIdent OBJECT IDENTIFIER ::= {tmonXM 1}
 tmonIdentManufacturer OBJECT-TYPE
 SYNTAX DisplayString
 ACCESS read-only
 STATUS mandatory
 DESCRIPTION "The TMON/XM Unit manufacturer."
 ::= {tmonIdent 1}
 tmonIdentModel OBJECT-TYPE
 SYNTAX DisplayString
 ACCESS read-only
 STATUS mandatory
 DESCRIPTION "The TMON/XM model designation."
 ::= {tmonIdent 2}
  

Wow! What language is that?

The MIB is written in ASN.1 notation. (The initials stand for Abstract Syntax Notation 1) ASN.1 is a standard notation managed by the ISO (International Organization for Standardization) and used in everything from the World Wide Web to aviation control systems.

A full description of ASN.1 is beyond the scope of this white paper - standard references to ASN.1 run up to 600 pages. When starting out, there are only a few things to know about ASN.1:

1. It's human-readable. This doesn't mean its necessarily easy to understand without a helpful guide like this white paper. It does mean you can view and even edit ASN.1 notation with basic text editors.

2. It's designed for communication between diverse computer systems, so it's the same for every machine. This doesn't mean every machine will no what to do with the information but it will at least recognize the ASN.1 notation.

3. It's extensible, so it can be used for describing almost anything. Once a term is defined in ASN.1, it can be used as a building block for making other terms. This can sometimes involve confusing references but with a little understanding and perseverance, you can usually find all the pieces to the puzzle.

4. It's worth learning. Equipment telemetry managers will be more confident in integrating SNMP telemetry with a basic understanding of ASN.1 in their skill set. As more equipment is being designed with some kind of SNMP capability, being comfortable with the related MIB files has real value.

What Every Telemetry Manager Needs To Know About the SNMP MIB

MIB files are composed of ASCII text and thus can be viewed using any word processor or text editor. When reading the MIB, it is not needed to read every single line of text. However, it is important for every telemetry manager to know some of the concepts embedded in the MIB. This includes:

• What characteristics of the device can be controlled remotely using the SNMP manager.

• What event reports the device can send to the SNMP manager.

• What information the SNMP manager can request from the device, and what Request for Comments (RFC) MIBs you need to support a device.

RFC MIBs are open-source, and can be found and downloaded with a simple web search for "RFC MIBs". The RFCs that define SNMP OIDs are part of a larger group of RFC documents that define the Internet as a whole. Individual vendors create their own MIBs that only include the OIDs associated specifically with their device. This structure is what makes an SNMP MIB object-oriented, a maximally efficient way of storing information.

How to Create SNMP MIB File?

Normally it's not necessary to create an SNMP MIB file. MIB files are not intended to be edited by the end-user. If you want, you could edit the text descriptions of managed objects to be more user-friendly, but it's better to simply use your SNMP manager's presentation software to create a useful display.

Keep in mind that equipment vendors create and supply you with that private MIBs. This means that these files are equipment specific, so it's important to make sure that you have the correct MIB for your gear type, model, and version number. This information should be provided for free by your vendor/manufacturer.

When you're evaluating new SNMP equipment, examine its MIB file carefully before you purchase. It might be strange that a manufacturer would add a component to a device and not describe it in the MIB. But the fact is, many devices have dubious MIBs that don't fully support all their functions.