MIBs - Management Information Base Modules
Introduction to MIBs
In the previous chapter, I stated that each managed device contains an agent, which accesses information about the device and makes it available to (and perhaps configurable by) the NMS. For example, an agent might respond to a query about such data as the number of bytes and packets in and out of the device, or the number of broadcast messages sent and received. In the Internet Network Management Framework, the definition of such a variable is referred to as a managed object. Any bit of information that an agent can access in its corresponding device can be defined. A collection of managed objects contained in a document is called a Management Information Base (MIB) Module, or, commonly, a MIB.
We can't really say that a MIB is a database of managed objects, because a database contains the actual data! Rather, a MIB is like the structure of a database. The data is kept elsewhere - perhaps in software or hardware on the managed device. The agent knows how to retrieve the data or to send an instruction to change a value.
In the next sections and chapters we will look at how MIB objects are described and defined, how different objects relate to one another, how an object is defined to be either alterable by the NMS or not (i.e., is it read-only or read-write?), and what the syntax of an object is. All of this general information about MIBs, their definition, structure, and syntax is defined in a set of RFCs: 2578, 2579, and 2580.
The Management Information Tree
The total corpus of management information is defined in such a way so that each managed object in any MIB module - whether standard or private - has a unique identifier, called the object identifier. The object identifier is a string of integers, separated by dots, that places the object at a specific node in a logical tree, which we'll call the Management Information Tree. The integers represent the nodes in the path from the root to, and including, the object itself. The nodes each have a label - that is the integer associated with the node - and a brief description.
For historical reasons that are not so interesting to most of us at this point in time, some of the nodes on the tree are irrelevant to us and make the object identifiers longer than necessary, as they contain what to us is some useless information. Figure 4 is a depiction of the top of the tree - the part that does not yet include much of interest. Looking at this structure (which is defined in RFC 2578), we see how the start of the object identifier is derived for every MIB object that we will look at. The MIB objects that are of interest to us are those under the mib-2 node, the snmp V2 node, and those under the enterprises node. We will find that management objects that are related are organized in groups, so that we don't have thousands of object nodes branching off directly under the mib-2 node, but we have nodes to represent groups, and sometimes sub-groups, etc., forming a hierarchy until we get to the managed objects.
Figure 4: Top of the Management Information Tree
Thus, looking at Figure 5 above, all objects in the standard MIBs have an object identifier that begins with 1.3.6.1.2.1 and all objects in the private (vendor-specific) MIBs have an object identifer that begins with 1.3.6.1.4.1. In the following chapters about MIBs, we will look at what comes under the mib-2 node and under the snmp V2 node, and we will look a bit at an example of an enterprise MIB, but we first should take a look at how these objects are defined.
MIBs and ASN.1
There are five basic attributes of a managed object:
- Object type (object identifier and descriptor) – unique ID and name for the object
- Syntax – used to model the object
- Access – access privilege to the managed object
- Status – implementation status (current, deprecated, or obsolete)
- Definition – textual description of the semantics of the object type
Let's take a look at an example of an object, and then we'll discuss the formal language used to define the object. To do this, I could just paste an example here, but I'd like you to have some hands-on, discover-for-yourself activities. So, take a break (this is probably getting pretty dry, anyway) and download and install an open software package called BlackOwl MIB Browser. If you are using a Windows platform (chances are pretty high that you are), then you want to download the file called 2.1.0 (I have no idea why it is called that - when you install it and click on the Help, that will not be the version number shown!). Or, as you can see, there is a Linux installer. Download the software - say, to your desktop - and then double click to install it. A user manual is available here.
As an alternate open software package, you can try SnmpB (and the file with the .exe extension is for Windows users). I tried both and there are more features in BlackOwl that are useful for my demonstration purposes (though neither package is complete nor can they compete with the commercially available stuff). The screen captures I'll be showing in my figures are from BlackOwl.
OK. I'm assuming you succeeded - it is quite simple. Run the program. You should get a window that looks like this (I closed the "Tip of the Day" box and requested that it never return):
Figure 5: BlackOwl MIB Browser
In the meantime, we'll use this software just to explore the Management Information Tree structure, the MIBs, and the formal language that is used to define objects and MIBs. Click on RFC1213-MIB on the left-hand side. You will see the text of MIB-2 on the right-hand side. We'll return to take a quick look at that, soon. On the top left, the left hand icon should have turned from grayed-out to brown. It is the "Load MIB" icon. Click on it. Or, in the top menu you can click on File/Load. Now you can use the "tree view", selected from the top menu by choosing View/Tree/Single Unified Tree. You can also click on the "Tree" tab at the bottom of the "Available MIBs"window, but then you need to also click on the green single palm tree icon at the top left (second from left), because I want you to see the whole Management Information tree. I know this sounds complicated, but if you are doing it along with me, then you'll see that it really is not. I am not bothering to put in a screen capture for each of these steps - I think it would make this page unnecessarily long. If you think screen captures of the icons, etc. would have helped you, drop me a note from the Contact the Dean box on the RAD Univesity home page, and you can try the user manual.
If you've succeeded in following along with me, the top left side of your BlackOwl window should look like this:
Figure 6: Collapsed Unified Tree
Now, click on the little plus sign next to the "iso" folder icon. Keep clicking to expand the tree until you get to the mib-2 node (and you should notice that the tree opens with the same nodes as depicted in Figure 4 above). When you click on the mib-2 node, you will see all the groups that are defined in the MIB module that is called MIB-2. (You might need to drag the border of that frame to enlarge it so that you can see the fanned-out tree.) It should look like Figure 7.
Figure 7: Expanded Tree
MIB-2 is the basic standard MIB (there was an earlier version that has been deprecated, which is why this one is called "MIB-2"). Parts of it have been replaced with new MIB modules, but mib-2 is still the node under which new modules are placed, and MIB-2 is as good a place as any to begin to understand how MIBs work. We'll look at this MIB (and some newer modules) in the next chapter, but now my goal is to have you look at just one object as an example. Click on the System Group, the first group under mib-2, and then click on the third object, which is called sysUpTime. Your window should now show (on the left side) what you see in Figure 8.
Figure 8: sysUpTime
The object calld sysUpTime (System Up Time) is the third object in the first group under the mib-2 node. That is why its Object ID is 1.3.6.1.2.1.1.3 (which you can see in the top right frame of your BlackOwl window). You can see that a .0 is appended to this Object ID (OID) in your window. That is because sysUpTime is a scalar object, which means that there is one leaf under the sysUpTime node, which is the single "instance" of this object. There are objects - and we'll see plenty in the coming chapters - that are tabular, for which there are multiple instances (represented by multiple leaves). For example, since a device might have multiple interfaces, there would be an instance of the ifSpeed (interface speed) for each interface. Perhaps that is why the OID and name are referred to as the "object type" - there might be several instances of one type.
I prefer to think of the Object ID for the managed object in the abstract - it is the location of the managed object in the tree, and therefore should not have the instance identifier appended. Only when I want to request a particular instance and refer to the value of an object in a message exchange would I append the instance identifier. I think that is consistent with the RFC, as you will see, shortly. However, the developers of this software probably appended the instance ID because users will want to use this tree to indicate for which object they wish to request a value.
Getting back to the sysUpTime Object ID, remember that we got to mib-2 with the Object ID of 1.3.6.1.2.1, so the appended .1.3 brings us to the first group (the System Group) and then to the third object in that group.
In the frame on the bottom of your window (I'm not presenting a screen capture - it is not particularly photogenic), you can see the Name (sysUpTime), the syntax (Type=TimeTicks, for which we will shortly see a definition), and that the "access" is read-only. This means that a manager cannot change the System Up Time. This makes sense - it is not up to the manager how much time passed from the last boot! This is information that a manager might find useful.
You also can see (if you've got good eyes - I think that SnmpB does a better job for this
feature) the description of the managed object (remember: the unit of information!). What is the
sysUpTime? In this case, the name is pretty intuitive, but we do need to be precise. It is defined as
"The time (in hundredths of a second) since the network management portion of the system was last
re-initialized." The description of the managed object exists for humans. The
agents and the NMSs don't need this - they just exchange data. Humans need to know the meaning of
the data. In this case, we see that the data is measure of time. A typical sysUpTime could be
displayed as 87:21:17:48.62. The hundredths of seconds was converted (by a management
application) for human consumption to
days:hours:minutes:seconds.hundredths-of-seconds.
Remember my example of an object called "color" and described as "the color of the device"? That description is not sufficient. We would say that the syntax of that object is integer followed by definitions of "0" for black, "1" for blush pink, etc. You can understand what I mean when I say that "humans need to know the meaning of the data". What the integers represent is for human consumption, so they know what integer to set the value of "color" to, so as to get the desired result (and for the fancy NMSs to provide meaningful graphic displays).
We saw that the syntax of the sysUpTime is TimeTicks. The TimeTicks syntax is defined in RFC 2578. TimeTicks is a non-negative integer associated with a unit of time. All of these syntax conventions are defined in the SMI (Structure of Management Information) RFCs, listed above. This brings us to the last topic of our introduction to MIBs, ASN.1. ASN.1 (Abstract Synatax Notation 1) is a formal notation, used for describing data transmitted by telecommunications protocols, regardless of language implementation and physical representation of these data. The SMI uses an adapted subset of ASN.1.
To see an example of how this looks, return to the MIB view in your left-hand frame by clicking on the MIB tab at the bottom. RFC1213-MIB should still be highlighted in the "Available MIBs" frame, and the right-hand frame shows the text of MIB-2 (you can see the complete RFC 1213, which contains MIB-2, by clicking on the RFC tab). All lines that begin with -- are comments. Scroll past the IMPORTS (these are definitions that were defined in other RFCs) and you'll see a line mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }. This indicates that mib-2 is the first node under the mgmt node, as we saw in Figure 4 above and in the fanned out tree.
Just after that line, you will see some textual conventions, which are new definitions for syntax subtypes (a more specific form of an existing type) that are defined here. Scroll down a bit more until your frame looks like Figure 9.
Figure 9: Definition of MIB-2 Groups
You can see that the system group is defined to be the first node under the mib-2 node, the interfaces group the second, etc. We'll be looking more closely at MIB-2 (using the tree-view) and additions to it in the next chapter, but now I just want you to take a look at the one object we already looked at, sysUpTime. So, continue scrolling just a little until your frame looks like Figure 10.
Figure 10: ASN.1 Notation for the sysUpTime Object
This shows the ASN.1 representation of sysUpTime. Notice, in particular, one detail of the ASN.1. In the last line, we see ::= { system 3 }. This means that sysUpTime is the third object in the system group (and no 0 is appended!).
This tutorial will not cover how to write in ASN.1, for several reasons. First of all, most people who need to understand SNMP don't need to know the details of how to write in ASN.1. Unless you will be writing MIBs in ASN.1, what you need to understand about the language will be best understood just by trying things and looking at examples (as we just did). And, even if you will need to write a MIB in ASN.1, these days you will most likely use a MIB-editing tool that helps you do that. There are several software packages that are (commercially) available that help you build MIBs and check the syntax. Therefore, we will now proceed to the next chapter and start to understand how MIBs work by looking more closely at MIB-2. For those who are interested, the references page has a link to a reference book on ASN.1, available online. However, remember that the SMI uses an adapted subset of ASN.1, so that you should refer to the RFCs, in any event, if you wish to become familiar with the details.
