MIB
MIB (Management Information Base) is part of a dictionary of what objects are available via SNMP. In most cases, an MIB is built for a device, but sometimes (like Cisco) it is built for a hardware release, a software version, or a set of features.
MIBs change and are updated over time. Make sure that you have the correct version of the MIB for what you are trying to monitor. Usually it will be the most recent version, but not always, especially if you are using old hardware/firmware.
How do you know which is the most recent version? Check the vendor’s website for the latest version and look at the last updated field and/or check the revision notes. See below to learn where the version and revision information is located in the MIB.
An MIB is meant to be read and imported by a computer, specifically an SNMP compiler on a management/monitoring server. It is human readable, but not in a way that is obvious unless you do your research, or read below. MIBs are written in a subset of Abstract Syntax Notation (ASN), an industry standard way of formatting data in a text file (designed way before XML, JSON, etc were even conceptualized). For SNMP, the subset of ASN is defined and documented as Structure of Management Information version 2 (SMIv2). I will defer to the standards docs if you really want to get deep into the weeds, but let’s look at what is in an MIB so you can open one up and at least understand what is going on.
I am going to use the SNMPv2-MIB for most of this discussion. The latest version as of this writing is published in RFC 3418 and is publicly accessible. It allows me to show examples of most scenarios you will find in a MIB file.
SNMPv2-MIB connects to the SNMP tree here:
iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1)
mib-2(1) and all higher level SNMP nodes are defined in RFC 2578 (SNMPv2-SMI)
Note: I will show you how SNMPv2-MIB connects to SNMPv2-SMI as the appropriate section of the SNMPv2-MIB is reviewed.
Here we go. What is in the MIB:
Start the definition of ‘SNMPv2-MIB’ MIB
Import OIDs, object types and macros from other SNMP MIBs
Note: The SNMP management server must have the referenced MIBs already imported or it cannot use this MIB until they are imported. In this case they are RFC defined MIBs that are most likely pre-installed, but that is not always the case.
Also note that this is the first time we see ‘mib-2’, the parent of this MIB in the OID tree. It has to be imported to later be able to attach and build off it.
MODULE-IDENTITY provides administrative information for the MIB. Data in the IDENTITY section includes the last time this MIB was updated, this can be used to determine which version of a MIB is the newest. Also in the IDENTITY section is the organization responsible for the MIB, the contact info for the MIB, the description of what the MIB is for, and a list of all MIB revisions, including the current revision.
The next section of the MIB lists three MIB OIDs that are no longer valid. If you want to see what was originally defined under these OIDs you can go back to RFC 1450. All SNMPv2-MIB definitions following RFC 1450 removed these and all child OIDs. Also note that RFC 1450 was the last listed revision (original version) in the previous section.
This is where the fun really starts. A new child is defined called system. It attached to mib-2 as node 1, creating mib-2.system(1). From what is available in this MIB, we only know that we imported mib-2 from a MIB called SNMPv2-MIB and that system attached to it. So what node id is mib-2 and what comes before mib-2 in the tree? That is where you will have to go back to the imported MIB, find mib-2 and determine what mib-2’s parent is, then repeat the process, usually going through multiple MIB files, until you get all the way back to the root node – iso(1).
Every MIB file down the tree will also have it’s own set of imports that need to be found and added to the management station in order for the all of the MIB files to be useable.
In this case there is only one MIB file that contains all of the parent nodes all the way to the root node. The full tree would be iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1)
The next section defines objects, we will start with the first three.
The first object defined is sysDescr. The syntax, or format, of the object is DisplayString. DisplayString is a text field of between 0 and 255 characters. MAX-ACCESS indicates that the object is read-only. This object can only be read by using an SNMP Get. STATUS of current indicates that it is still relevant and in use. We will look at an object that is not current later. Next is DESCRIPTION. This is a description of what the object contains and/or is for. Finally, :: = closes out the object definition and connects it to the tree. In this case, sysDescr connects to system, the node just created above, as node 1 – iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysDescr(1)
sysObjectID is similar. The main difference is the the SYNTAX is OBJECT IDENTIFIER or OID. When you read this object it will return an OID. It also connects to the SNMP tree at system, but is node 2 – iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysObjectID(2)
sysUptime is as SYNTAX of TimeTicks. TimeTicks is a counter, starting at 0 when the device booted and incrementing in hundredths of seconds. sysUptime connects to the SNMP tree at system again, but is node 3 – iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUptime(3)
Note: you will see this OID often when I configure monitoring of a device.
Below, sysContact is the same SYNTAX as iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysDescr(1), but sysContact has a MAX-ACCESS of read-write. You could use an SNMP Get to read the object’s value, or you could use an SNMP Set to update the object with a new value. SysContact connects to the SNMP tree at system again, but is node 4 – iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysContact(4)
The next few nodes defined in the MIB don’t introduce any new or interesting concepts, so we will jump to sysORTable.
sysORTable has a SYNTAX of ‘SEQUENCE OF SysOREntry’ and a MAX-ACCESS of ‘not-accessible’
SEQUENCE OF notifies you that a table is being defined. A table is 0, 1 or more rows of objects. In this case they are rows of objects that communicate what MIBs are supported on the device.
sysOREntry has a MAX-ACCESS of not-accessible. This indicates that if you query this object, not data will be returned. This object is a container that holds the rows that follow.
sysOREntry defines the columns of the table. There are 4 columns: sysORIndex, sysORID, sysORDesc and sysORUptime
The sysORIndex is also not-accessible. It is used to identify the row.
sysORID, sysORDesc and sysORUptime all contain data as defined in the objects listed.
To access the data for row 1 (sysORIndex = 1) you would query the the following 3 OIDs:
iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysORTable(9).sysOREntry(1).sysORID(2).sysORIndex(1)
iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysORTable(9).sysOREntry(1).sysORDescr(3).sysORIndex(1)
iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysORTable(9).sysOREntry(1).sysORUpTime(4).sysORIndex(1)
MIBs can also contain TRAP information. Traps are SNMP messages sent from a managed device to the management server when a defined event occurs (not waiting for the SNMP management server to GET the data). See the upcoming post on SNMP Traps for further information.
All objects, and in this case object definitions, once defined are never to be deleted. If an object is never meant to be used again it should be deprecated (no longer valid) or set to obsolete (one or more new objects have been created to take this one’s place). The status is in reference to the current MIB version. The only valid values are “current”, “deprecated” and “obsolete”.
The following example, taken from the SNMPv2-TC MIB, shows the definition of a new object type called ‘TimeInterval’
The important parts are the object name = TimeInterval, the Status = current (valid as of this version of the MIB), the Description (what the object is and how it works – in this case every interval is 1/100th of a second), and the Syntax (how the data is stored) – in this case an Integer value.
A couple of final notes.
MIB object names are supposed to be globally unique. There is no single standards body that reviews, validates and approves all object names, so there are duplicates in existence. Duplicate names have been found in MIB files of different vendors, in different MIB files of the same vendor, and even in the same MIB file in at least one case. This is one of the reasons that I prefer to use the name/number notation when listing an OID. I have found this is the only way to be sure we are identifying the correct OID and providing some human recognizable context.
Besides object names not always being unique, there are other MIB standards that have been misinterpreted, misunderstood, or just implemented incorrectly in MIB files. Some MIB interpreters are more forgiving of these mistakes, others are not. There have been a few cases where I have had to modify a MIB file slightly to fix a problem that causes it to not import. This is not recommended but, in my case, was necessary.
If you read my entry about the SNMP commands, like GET and SET, you will learn that the only information sent to a device to identify an object is a value representing the dotted decimal OID value. The names are never sent.
Have questions, thoughts, comments, corrections, etc. I welcome and will try to respond to all feedback.
Thank you