Introduction to SNMP

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, calledcpsModuleModel. 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.

MIB Table Indices

Indices are the means through which the “dynamic” portion of the MIB tree mentioned above are constructed.

The definition for each variable in a MIB Module contains both a description of the “fixed” portion of that variable’s OID and (where applicable) a list of indices that make up the dynamic portion of the OID. To form a complete OID, we take the “fixed” portion of the OID and append the index values. This forms a complete OID that (assuming that it exists) has a data value associated with it.

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 forcpsModuleModel 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.

Notation

There are many situations in SNMP where a numeric value has a text label associated with it in the MIB Module file. When such a values is written about or displayed, it is common to list both, with the text label followed by the numeric value in parenthesis. This notation is used both for values of MIB variables and for branches of the MIB Tree.

Several examples can be found in this document. Our sample OID contains “cpsModuleModel(3)” and many other label/numeric pairs. In this case, the “3” refers to the 3rd branch of the OID tree from the above level, and “cpsModuleModel” is the text label assigned to this branch in the MIB Module file.

The above ‘Values’ example contains linkDown(2). This is a value of “2” which has a text label of “linkDown“.

SNMP Operations

In SNMPv1, there are four types of transactions that can occur between the Agent and the NMS:

    • Get
    • The Get operation is performed by NMS when it wants to retrieve management information contained in an Agent. To use this request, the Agent must know exactly what it is looking for. In the Get Request, the NMS provides a complete OID to the Agent. Unless there is an error, the Response from the Agent contains a variable binding containing the the same OID and the data associated with it. If the OID does not exist or does not have any data associated with it, the operation fails.
    • Getnext
    • Like a Get, this is a request by an NMS to retrieve management information contained in an Agent. The difference is that the NMS doesn’t need to know the complete OID to make the request. This is useful in stepping through dynamic lists of MIB variables (which cannot be not fully specified in the MIB Module), like the list of cabinets in a Point System stack. In the Getnext request, the NMS provides either a complete OID or a fragment of an OID. Unless there is an error, the Response from the Agent is a binding containing the OID and Data of the item immediately to the right of the specified OID in the tree. The Agent will move up or down the tree as required to find the next OID that can be bound.
    • The Getnext operation can be used repeatedly to retrieve all of the information in the portion of the MIB Tree that the agent knows about. This is known as a

MIB Walk

    • Set
    • A Set operation is used by an NMS to tell the Agent to change a peice of management information contained in that Agent. In the Set Request, the NMS provides a complete variable binding to the Agent, expecting the Agent to write the provided data into the data area associated with the provided OID. If the OID does not exist, does not have any writable data associated with it, or for any reason cannot accept the provided data, the operation fails.
    • Trap
    • A trap is a one way notification from the Agent to the NMS, when some urgent condition occurs, such as the failure of a communications channel. It is the only operation that is initiated by the Agent rather than the NMS.

Summary

  • The term Management refers to the ability to monitor and configure equipment remotely via the network.
  • The computing entity within the managed equipment that performs management functions is called the Agent.
  • Each piece of equipment has a vendor-defined list of manageable features. This list is called a MIB, or Management Information Base.
  • Object IDs are names used to refer to particular items of interest within an SNMP agent. Usually, these items are individual pieces of management data. All OIDs have a fixed portion, and some also have a dynamic portion.
  • The MIB Module document is a human and machine readable description of a MIB. Equipped with this document (at a minimum), a network management application can be used to manage a device.
  • The four basic SNMPv1 operations GET, GETNEXT, SET, and TRAP are used to exchange information between an Agent and a network management application.

 

Questions?