Simple Network Management Protocol Primer

This document contains descriptions of SNMP concepts that explain the behind the scenes workings of SNMP Agents and Applications. For most users, the amount of effort required to understand these arcane details will outweigh the benefits. The fact of the matter is that SNMP is anything but "Simple." Fortunately, these details are masked by Network Management Station software such as Transition Networks' Focal Point and Embedded Web Server. If this document is insufficient to allow you to understand SNMP to your satisfaction, then you should either read "Understanding SNMP MIBs" by David Perkins and Evan McGinnis (Prentice Hall), or just relax and allow Focal Point or the Web interface to take care of things for you.

Basic SNMP Concepts and Terminology

As new terms are introduced, they will be displayed in bold font. Pay special attention to these terms, because after their introduction, it will be assumed that you understand them.

The primary purpose of SNMP is to allow the network administrator to monitor and configure devices on the network, remotely via the network. These configuration and monitoring capabilities are collectively referred to as Management.

The network-attched computer that resides within a manageable device and performs management functions is called the SNMP Agent.

A computer that is used by the network administrator to work with various Agents around the network is known as a Network Management Station or NMS. High-level Management software (like Focal Point) that runs on a NMS is referred to as a Management Application. Usually, a single NMS will manage multiple Agents.

Designers of network equipment decide which features of their products will be accessible via SNMP, and then create hardware and software to support this management. The collection of the descriptions of all of these features is called a Management Information Base or MIB, and a description of an individual manageable feature in the MIB is referred to as a MIB Variable.

In order for the NMS to be able to carry on meaningful conversations with the Agent, the NMS must have a description of all of the manageable features the Agent knows about. To this end, each type of agent has an associated document called a MIB Module, which contains these descriptions. MIB Module files are loaded into the NMS. The primary purpose of the MIB Module is to provide documentation of the name and description of each and every manageable feature a particular type of Agent knows about. Of course, some Management Applications (like Transition Networks' Focal Point) are provided with a large amount of custom information (in addition to the MIB Module document) so that they can provide advanced features such as graphical representation of the equipment.

Note that strictly speaking, the MIB is nothing but a set of ideas. However, since the MIB Module is the most tangible representation of the MIB, the terms "MIB" and "MIB Module" are used interchangeably by many.

To prevent naming conflicts and provide organization, all of the manageable features of all products from all vendors are are arranged into one enormous tree structure referred to as the MIB Tree or "The MIB," which is managed by the Internet Assigned Numbers Authority (IANA). Each vendor of SNMP equipment has an exclusive section of The MIB Tree that they control.

Each branch of the MIB Tree has a number and a name, and the complete path from the top of the tree down to the point of interest forms the name of that point. A name created in this way is known as an Object ID or OID.

Nodes near the top of the MIB Tree have names that extremely general in nature. (You have to move all the way down to the fourth level before you get to "Internet"!) The names get more and more specific as you move down, until you reach the bottom, where each node represents a particular feature on a specific piece of installed hardware known to a particular Agent.

A sample OID

The remainder of this document uses examples from the Transition Networks Point System product to illustrate SNMP concepts that are applicable to all SNMP compliant products.

This figure shows just a few of the thousands of items (i.e. Variables) in the MIB Tree. We will now take a close look at one of them, called cpsModuleModel. cpsModuleModel is the MIB Variable that allows us to ask the Point System Agent what type of device is in a particular slot in a particular cabinet.

Looking at this example, it becomes evident that some portions of the MIB Tree are fixed, and others are dynamic. In our example, the path through the tree from the root (at the top) down to cpsModuleModel never changes because (to that point) it is a generic reference to a Manageable Feature posessed by every example of the product. This unchanging portion of the tree is clearly insufficient, since a specific user can install one or more cabinets in a Point System stack, and each cabinet can have from 2 to 19 slots - and we need to be able to talk specifically about each of those slots. To make the leap from 'generic references to features' to 'specific pieces of installed equipment,' we need a dynamic section on our tree. This dynamic section, which appears at the bottom of the tree, is built by the Agent in response to the hardware it sees. In this example, we have a single cabinet with a serial number of 3562, and the first three slots of this cabinet are shown.

If we wanted to know what type of card was installed in the second slot of our cabinet, what OID would the NMS need to ask for? To find the answer, trace from the top of the tree down to the item we want, recording all of the names/numbers as we go:

   iso(1).org(3).dod(6).internet(1).private(4).transition(868).products(2).chassis(4).card(1).slotCps(2).cpsSlotSummary(1).cpsModuleTable(1).cpsModuleEntry(1).cpsModuleModel(3).3562.3
or
   1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3

In day-to-day practice, these long-form OIDs are rarely seen. It is far more common to start from the lowest "fixed" branch of the MIB Tree like so:

   cpsModuleModel.3562.3

This is theoretically ambiguous since there is nothing to stop two different vendors from each having MIB variables called cpsModuleModel, but in actual practice problems due to conflicts are very rare, primarily because the OIDs are shortened only for use by people. Behind the scenes, the Agents and Management Applications continue to use the long form OIDs.

So, for example, the variable cpsModuleModel has a "fixed" OID of

   1.3.6.1.4.1.868.2.4.1.2.1.1.1.3

If we ask the Agent about this OID, the Agent will return an error, because the OID is ambiguous; cpsModuleModel is used to tell us the model of a device in a particular slot in a particular cabinet, but we haven't yet specified which cabinet or which slot. The MIB Module definition for cpsModuleModel contains two indices to help us out of this predicament: BIA and slot. To form a complete OID about which the Agent is able to answer questions, we append a value for BIA and a value for slot. Assuming that our cabinet serial number and slot are the same as in the previous example, we get the following OID:

   1.3.6.1.4.1.868.2.4.1.2.1.1.1.3.3562.3

which is usually expressed this way:

   cpsModuleModel.3562.3

The fixed portion of the OID represents everything about the object's location in the tree that is known to the vendor at the time of manufacture. The dynamic portion of the OID represents that portion of the object's location in the MIB tree which cannot be determined until the equipment is installed and initialized.

What if there aren't any indices?

MIB Variables that occur only once in the entire Agent (rather than being repeated for each of several devices) have no indices. When the definition of a MIB Variable does not contain any indices, the placeholder value ".0" is used to indicate this. For example, it is neither necessary nor permissible to specify a cabinet or slot when asking about the Group Control String. There is one Group Control String for the entire system, and its complete OID is:

   cpsGroupCtrl.0

or

   1.3.6.1.4.1.868.2.4.2.2.3.1.0

The ".0" at the end says "no indices are required."

Values

The Value of a MIB Variable can take on many forms. Strings and integers are very common, but the most common type is an enumeration.

The values of normal integers don't have any particular meaning beyond perhaps a count of some sort. '3' just means that there are three of something. An enumeration is a special integer that doesn't count anything. Instead, each integer value corresponds to some particular meaning which is reflected in a label that is associated with that integer value.

For example, the MIB variable cettf100FiberLink indicates the link status of the fiber port on the device, and it has an enumerated value of either 1 for linkUp or 2 for linkDown.

The combination of a complete OID and the value and data type associated with that OID is called a Variable Binding. For example:

   cettf100FiberLink.3562.3 is an integer with a value of linkDown(2)

If an OID does not have any data associated with it (this is fairly common), it is impossible to create a variable binding for that OID. For example, the OID '1.3.6.1.4.1.868.2.4.1.2.1.1.1.3' (from our MIB Table Indices example above) cannot be bound because it is incomplete.