OID, vey!

[SlightlyLoony]

Many of the people who are responsible for running Discovery aren't very familiar with the Simple Network Management Protocol (SNMP). The seemingly endless stream of acronyms (SNMP, OID, MIB, etc.) associated with SNMP don't make it any easier to understand. So what is SNMP, and how does Discovery use it?

SNMP provides three general functions: reading information from a device (about it, its configuration, and its condition), writing information to a device (to change its configuration), and event messages (about changes in its condition). Discovery only uses the first of these general functions — reading information.

To read an individual piece of information from an SNMP-enabled device, you need three things: the device's IP address, the community string (discussed in yesterday's post on credentials), and the Object IDentifier (OID) for the particular piece of information you want. OIDs are written as strings of numbers separated by periods, like this: "1.3.6.1.2.1.1.1". Each OID is a unique "address" that defines the location of a specific piece of information — 1.3.6.1.2.1.1.1 is the location of the system description for any SNMP-enabled device. If you query the device for a particular OID, you'll get back the information — a number (like 5.6), a string (like "Cisco 2610"), or any of dozens of other information types.

Different kinds of devices (routers, printers, computers, etc.) provide different kinds of information through SNMP. Some devices only provide a few individual pieces of information (sort of like name, rank, and serial number); others provide millions of individual pieces. If every make and model of every kind of device had its own ideas about which information to provide, and what OID that information was located at, SNMP would be chaos. Fortunately for all of us, the folks who invented SNMP thought of this, and provided some order to this world with the notion of a Management Information Base (MIB). A MIB defines a hierarchy of OIDs for a particular category of information. For example, the MIB known as "MIB-2 IP" defines all the OIDs "under" OID 1.3.6.1.2.1.4 (1.3.6.1.2.1.4.1 and its children, 1.3.6.1.2.1.4.2 and its children, etc.). The MIB defines the OIDs, their human-readable names, and the type of data they provide. For example, the MIB-2 System MIB defines 1.3.6.1.2.1.1.1 as "sysDescr" and as a string type. You could write that OID as either 1.3.6.1.2.1.1.1 or 1.3.6.1.2.1.1.sysDescr; they are exactly the same thing. Similarly, other MIBs define the rest of the numbers in that OID, so you could write iso.org.dod.internet.mgmt.mib-2.system.sysDescr instead of 1.3.6.1.2.1.1.1; again, they are exactly the same thing. There are many online tools that let you explore MIBs; one of my favorites is the OID Repository (at http://www.oid-info.com/index.htm ).

There are two kinds of MIBs out there. First, there are standards-based MIBs, agreed on by standards organizations and published for the whole world to see. All the MIBs cited so far are standards-based. All SNMP-enabled devices are mandated to support certain standards-based MIBs (though not all actually comply, unfortunately). For many kinds of devices (routers and switches are good examples), support of standards-based MIBs is almost universal — this makes it possible for Discovery to query and analyze a single MIB for these kinds of devices, but still get them all. The other kind of MIB is the proprietary MIB — a MIB that is specific to one maker's devices, or sometimes even to one make and model of device. Often these proprietary MIBs simply extend the standards-based MIBs. Cisco's proprietary MIBs are a great example of this: their routing MIB, for example, provides much more information than the standards-based MIB, which they also support. Other makers just went their own way, supporting their proprietary MIB but not the standards-based MIB. APC's UPSs are a good example of those: even though there is a standards-based UPS MIB, APC does not support it in their devices — instead, you have to use their proprietary MIB. This complicates life for Discovery, because for UPSs (support for which will be in the next release) we have to use two MIBs: one for APC, and one for every other UPS maker.

If you look in any SNMP probe in our Discovery product, you'll see a parameter called "[no-glossary]oid_spec_list[/no-glossary]" This parameter defines the OIDs that probe will query. Each line in that parameter starts with either "walk" or "table"; those are commands that the probe interprets. The walk command tells the probe to query the specified OID and all its children. The table command tells the probe to query the table at the specified OID, but only those child OIDs specified in the comma-separated list. You shouldn't modify the probes that come with Discovery, but you can make your own SNMP probes to query different OIDs (you'll need a matching sensor, too).