The ABCs of MIB
|
|
|||
|
|
This week we tackle the topic of MIB . . . no, not "Men in Black II" (which we quite enjoyed - essentially a remake of the first MIB movie with better effects). No, this MIB is the Management Information Base of SNMP.
Actually there is only one SNMP MIB - all the things that are generally referred to as MIBs are really variants and extensions of the basic data structure.
As we said a couple of Gearheads ago: The MIB, which was defined by the Internet Engineering Task Force (IETF), is a hierarchical collection of objects organized in a tree. To prevent naming conflicts, the Internet Assigned Numbers Authority manages the structure and objects in the tree.
The MIB contains the name, object identifier (a numeric value), data type and indication of whether the value associated with the object can be read from and/or written to. While the top levels of the MIB are fixed, specific subtrees have been defined by IETF, vendors and other organizations.
At the top of the MIB tree is the most general information available about a network, and each branch below contains more detail about specific devices and services.
According to RFC 1155, "Structure and Identification of Management Information for TCP/IP-based Internets": "The root node itself is unlabeled, but has at least three children directly under it: One node is administered by the International Organization for Standardization, with label iso(1); another is administered by the International Telegraph and Telephone Consultative Committee, with label ccitt(0); and the third is jointly administered by the ISO and the CCITT, joint-iso-ccitt(2)." There are many, many layers under those.
Variables in MIB are named using Abstract Syntax Notation 1 (ASN.1), an international standard for representing data types and structures. For example, the MIB variable in the IP subtree that counts incoming IP datagrams is named internet.mgmt.mib-2.ip.iplnReceives.
But when sending and receiving messages under SNMP, variable names are not stored as text strings. Instead, a numeric form of ASN.l is used to represent each named node in the tree. This is not only computationally simpler but also reduces the size of packets.
These numeric labels create what is effectively an outline numbered ID, starting with the root of the tree as 1. So, 1.1 is a child of the root and a sibling of 1.2 and a parent of 1.1.n.
A complete numeric name that starts from the root of the MIB tree is called an object ID (OID).
So for our example using the variable iplnReceives, the sequence of numeric labels that refer to it are 1.2.1.4.3.
But that's not all. In an SNMP message the numeric representation of a simple variable name will have a zero appended to signify that the name represents the only instance of the variable in the MIB. In other words, there are no other identically named variables. So, for iplnReceives, the exact form is "1.2.1.4.3.0."
Now, remember that a manageable device is called an agent and a computer that is used to work with an agent is called a network management station (NMS). The management software that runs on an NMS is called a management application.
Network equipment that is designed to be managed by SNMP must implement a MIB, and the management application must be told what can be managed on the agent. The collection of the descriptions of all the manageable features might be either a standard or custom MIB subtree, which is described by a MIB module. MIB module files are loaded into the NMS so that the device can be managed.
You might be wondering how many MIB subtrees there are. The Web site mibCentral boasts that it indexes "over 4,600 SNMP MIBs representing over 630,000 MIB object definitions."
Be that as it may, the reason we started on the topic of SNMP (see "Logging messages with SNMP") was that like syslog, SNMP is a standard that includes a mechanism for devices such as routers to send status and error messages. This mechanism is called a trap.
SNMP trap messages contain OIDs followed by one or more variables each with a value that the NMS decodes by mapping the OID to its variable name. The NMS then maps the data associated with the OID into its display, logging and automated procedure subsystems.
So, we now know what syslog messages are and what SNMP traps are. How can we handle them all? We'll discuss this issue next week.
State your status to gearhead@gibbs.com.
RELATED LINKS
Comments and suggestions to gh@gibbs.com.
Gibbs Forum
The place to discuss Gibbs's columns.
Check out this week's edition of
Backspin for more musings from Gibbs.
|
|
|
|||||

