Exploring MIB-2
MIB-2 Groups
In the previous chapter, you saw (in Figure 7) that MIB-2 contains a number of groups. Before we proceed to examine these groups further, we will import the SNMPv2 MIB, which updates MIB-2 (and the objects of some of the groups). SNMPv2 was introduced in 1993, and yet you might find that there are many devices that still only support the original MIB-2. The SNMPv2 MIB was updated several times, and the latest version appears in RFC 3418.
There are several methods that you can use to import this MIB into your Blackowl MIB Browswer. I'll use the method where you import from the IETF (the source!), so click on the IETF button in the tool bar, towards the top, and enter 3418 as the RFC number and click OK. For me, it took just seconds to import the MIB. If you have difficulty (who knows - perhaps you aren't able to connect to the IETF), you can search (using your favorite search engine - give me two guesses which one that is) for a text version of RFC 3418, and that should work, too, by using the URL button and entering the URL that you found. The left side of your Blackowl window should show SNMPv2-MIB (and I selected it) in the "Available MIBs" frame, as shown in Figure 11.
Figure 11: SNMPv2 MIB Imported
Now, click on the brown folder icon on the top left of the tool bar, to load the MIB that you just imported. You will see two loaded MIBs. Switch to the Tree view (you did that before). You should see one unified tree, with the top folder called iso. If you see two separate top-level folder, click on the lone palm tree icon to get one unified tree. Expand your tree by clicking the plus signs until it looks like Figure 12.
Figure 12: SNMPv2 MIB Loaded
The groups under the mib-2 node might look the same as before (Figure 7 in the previous chapter), but some of the group contents are different. Compare Figure 8 in the previous chapter to what you get if you click on the system group, now, shown in Figure 13.
Figure 13: The System Group including SNMPv2 Changes
Loading the SNMPv2 MIB incorporated other changes that you can't see because we didn't expand on any groups other than the system group before loading the SNMPv2 MIB. The very curious can unload the SNMPv2 MIB, compare all you want, and then reload to continue the tutorial.
Scalars and Tables
One of the most boring things I could think of doing for you would be to fan out the tree and look at each object, one-by-one, in the tree. (Well, perhaps watching the grass grow could be more boring.) So, we won't do that. Feel free to explore all you want. Once you see a few more examples of objects, you'll be able to understand any other objects that intrigue you.
As mentioned previously, managed objects can be either scalar or tabular. You already saw one example of a scalar object (the sysUpTime in the previous chapter). It is important for you to understand how tabular information is represented, and we will look at a few examples of MIB tables - but I misled you with this section title. We'll only do tables in the next chapter. I'm doing that to keep the length of this page from getting out of hand. Before the tables, we'll look at another couple of scalar objects, to see a variety of syntax types.
The syntax of the sysUpTime is TimeTicks, a type of integer. See if you can see the syntax of the sysContact object in the bottom frame. (I know, the font is tiny.) It is defined as OCTET STRING. As defined in section 7.1.2 of RFC 2578, the RFC that defines the Structure of Management Information: "The OCTET STRING type represents arbitrary binary or textual data." In the tiny letters in the bottom frame you can see that the sysContact is the "textual identificaton of the contact person for this managed node, together with information on how to contact this person." So, an OCTET STRING makes sense for this object.
But you will get more complete and accurate information by looking in the text of the MIB itself. (I would call this a "bug" in the software - they might call it a "feature") I'll remind you how you can view the RFC: Switch to the MIB view with the tab on the bottom of the tree frame, make sure the SNMPv2 MIB is selected in the "Available MIBs" frame, and then scroll down in the right-hand frame until you see the sysContact object, as in Figure 14.
Figure 14: sysContact
Now we see that the syntax of sysContact is DisplayString. What is the difference between that and OCTET STRING? A DisplayString is a subtype of an OCTET STRING, and is defined as such in section 2 of RFC 2579, using a TEXTUAL-CONVENTION MACRO. If you look at the definition in the RFC, you'll see that a DisplayString is specifically ASCII text, while we saw that an OCTET STRING can also be binary. So, a DisplayString is more specific.
Another difference that we see in the text of the MIB vs. the tiny-font display of Blackowl is that the description of sysContact has another sentence: "If no contact information is known, the value is the zero-length string." This is further information that was included in SNMPv2 to instruct implementors what to do in the event that no one configured system contact information. (I would also call this a "bug" in Blackowl - that this sentence does not appear in the tiny-font frame that we get when we select the object in the tree. Without doing extensive checking, I suspect if the object ID already exists in the original MIB-2, Blackowl does not override the information with the SNMPv2 MIB.)
The other example of a scalar we'll take a look at is one of the statistics. There are loads of statistical values that are defined in the MIBs - we'll just pick one. Go back to your tree view and expand the UDP group. Select udpInDatagrams, as seen in figure 15.
Figure 15: udpInDatagrams in the Tree
However, the UDP group was also updated from the original RFC 1213 that contains MIB-2. So, let's import the UDP MIB from RFC 4113. You remember how to do that - click on the IETF button on the toolbar, enter 4113 as the RFC number, and click "OK". Whoops! This time, we are prompted with a new little window. It shows a "dependency tree". That means that we need to first import the other RFC that is marked in red: the INET-ADDRESS-MIB. (The other two dependencies that are marked in green are already contained in a folder where the software is installed, though they do not appear in the Available MIBs frame.) The RFCs marked in green are the SNMPv2-SMI (Structure of Management Information) and the SNMPv2 Conformance Statement, which are RFCs 2578 and 2580.
So cancel the compile for the UDP MIB, and let's load the INET-ADDRESS-MIB, which is RFC 4001. My experience determined that things will work better if we import RFC 4001 as the MIB text (and not as an RFC from the IETF), so click on the URL button and enter this URL: http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/INET-ADDRESS-MIB and click "OK". Now you can import the UDP MIB. Click on the IETF button and enter 4113. Now you can select the UDP MIB from the list of available MIBs and click on the upload button in the top left of the tool bar. Switch to the tree view, and if you've been following along and doing this, you should end up with what looks like Figure 16.
Figure 16: udpInDatagrams in the Tree with SNMPv2 Updates
Notice that the UDP Group with the new UDP MIB has more objects in it (compare with Figure 15). OK, back to the goal: to look at the udpInDatagrams. Of course, I could have had you look at it in the original MIB-2, but I want to drive home the idea of how MIB-2 has been given a serious overhaul with many new RFCs (and several iterations, too), and yet it all shows up under the same MIB-2 node in the tree. Aside from updates to the System Group, the SNMP Group (both of which we updated when we imported SNMPv2) and the UDP Group (which we also imported), there are updates to the IP group (RFC 4293), the TCP Group (RFC 4022), the Interfaces Group (RFC 2863), and the ICMP Group, which is now defined in the same RFC as the IP Group (RFC 4293). In fact, all relevant groups were updated! The EGP Group and the AT Group are both obsolete - when we look at tables, you'll see why the AT group was deprecated. And EGP is an old inter-domain routing protocol, so no one uses it any more.
This object name udpInDatagrams is pretty intuitive. It is described as (look at the bottom left frame in the tiny font) "the total number of UDP datagrams delivered to UDP users." The syntax in that little frame is listed as Counter. However, as before, we get the more correct object definition by looking at the MIB text, so switch to the MIB view and look at the text - scroll until you see the definition of udpInDatagrams, as shown in Figure 17.
Figure 17: udpInDatagrams Object Definition
We now see that the syntax is Counter32, which is a subtype of INTEGER and is defined in Section 7.1.6 of RFC 2578: "The Counter32 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero." The original Counter had the same maximum, but it was replaced by Counter32 because a Counter64 was also defined. we also see an explanation of discontinuities, which helps the user understand why, if s/he graphs the values of udpInDatagrams, it might start again from 0 even though it didn't reach the maximum value (and you already know what sysUpTime is).
Now, on to the tables!
