Simple Network Management ProtocolSNMP

The most widely adopted standard provides a way for devices and consoles to communicate.

As a multitude of forward-looking academics , vendors, and standards bodies recognized in the late 1980s, network management is a big job in many different ways. In particular, management is too big a job for any one vendor to handle. Manageability requires instrumentation in many devices from numerous vendors ; it requires accessibility or transportability across the network, as well as on dedicated out-of- band channels; and it requires programming interfaces for a multitude of general purpose, as well as specialized, applications. It's all too evident that multivendor network management is impossible without a standard.

In developing such a standard, the ISO bet on a horse named CMIP (common management information protocol), while the Internet world bet on the Simple Network Management Protocol, or SNMP. And you know what happens when bloated, unwieldy OSI standards compete with (relatively) sleek Internet standardsInternet standards get implemented in products and OSI standards collect dust on shelves . Since 1990, when RFC 1157the Internet Engineering Task Force document that defined SNMPbecame an Internet standard, practically every widely deployed network management system has used SNMP.

SNMP management has three components . The first component is the Structure of Management Information (SMI), which is a sort of toolkit for creating a management information base, or MIB. The SMI identifies the permissible data types and spells out the rules for naming and identifying MIB components. It defines the structure of the SNMP naming mechanism. The MIB, which represents the second component of SNMP, is a layout or schema for information relevant to managing networks and their component devices. The third component, which the Simple Network Management Protocol itself defines, is the different possible payloads or Protocol Data Units (PDUs) that form legitimate management messages.

SNMP is most often implemented over IP. In fact, UDP port numbers 161 and 162 identify SNMP agents and SNMP managers, respectively. But nothing in the standard prevents SNMP messages from being delivered with TCP, HTTP, or nonInternet protocols, such as IPX or AppleTalk's datagram delivery protocol.

The SMI

The SMI specifies the allowable data types in the MIB, and it spells out the ways data can be represented. Also, it defines a hierarchical naming structure that ensures unique, unambiguous names for managed objects, which are the components of a MIB. Compared with the objects that general purpose programmers use to build applications, SNMP-managed objects are very simple and stripped down. MIB objects typically have six or so attributes. For instance, an object usually has a name , such as ifInErrorsortcpAttemptFails; an object identifier in dotted decimal form, such as 1.3.6.1.2.1.2.2.1.14; a syntax field, which selects one of several possible data types such as Integer, IPAddress, or Counter; an access field, which selects among "not-accessible," "read-only," "read-write," and "write-only"; a status field consisting of either "mandatory," "optional," "deprecated," or "obsolete"; and a text description of the object.

MIB objects are static; they're compiled from a text-like description language to a binary form that agents and managing processes can load. While the standard MIBsMIB-2 is the current generic TCP/IP MIB standard, and specific MIBs have been adopted for bridges, printers, and other entitiesprovide a useful common denominator for management application developers, most vendors find it necessary to define their own proprietary objects to take advantage of their products' capabilities.

The SMI is two layers of abstraction away from the sort of management data that IT staff and users care about. It sets the rules for defining MIB objects, which are one layer of abstraction away from management data. All these abstract rules and reserved words make it possible to have machine-readable specifications that remain comprehensible to humans . The SMI enables a vendor to write an SMI-compliant management object definition (perhaps one called PacketsContainingTheWord-Spam), run the text through a standard MIB compiler to create executable code, and install the code in existing agents (for instance, agents with the right hardware and software to count instances of the word "Spam") and in management consoles that could then begin generating reports and charts about such occurrences.

MIB

The MIB is a hierarchical name space, with the registration of its nodes administered by the Internet Assigned Numbers Authority (IANA). According to the hierarchy in the figure, the object ID for every relevant MIB object must begin with either 1.3.6.1.2.1 (which represents the mib-2 node) or 1.3.6.1.4.1 (the enterprises node). The term MIB is also used to refer to specific collections of objects used for particular purposes. Thus, MIB objects under the mib-2 node include the RMON (remote monitoring) MIB objects and other generic MIB objects, while those under the enterprises node include all proprietary MIB objects. It has been estimated that there are 10 times as many proprietary MIB objects as there are generic ones.

MIB Structure: Like many hierarchical name spaces, the MIB begins with an unnamed root node. The node "mib-2" can be uniquely identified with the object identifier notation 1.3.6.1.2.1, and the node "sun" has the object ID 1.3.6.1.4.1.4.2. Administrative responsibility follows the tree structure. Thus Sun can assign the nodes beneath "sun" though it must register the names with the IANA.

Each MIB object has a value associated with it according to the syntax part of its specificationfor example, the number of packets that have come in since the last system reset, the number of clock ticks since the last reset, or the administrative state of a router. When a MIB object is instantiated on a device or other entity, the value associated with the object is sometimes called a MIB variable. SNMP agents store MIB variables and send them to SNMP managing processes (or consoles) when they are asked to. The value of a MIB variable is the basic unit of useful management information.

MIBs are often divided into groups of related objects. MIB-2 has 10 groups, including "system," "interfaces," "ip," "tcp," "udp," and "snmp." The RMON MIB for Ethernet segments has nine groups, including "statistics," "history," "alarm," "event," and "capture."

While RMON is an extension of the MIB, traditional SNMP agents are not capable of capturing most RMON data. Special RMON probe devices or built-in probe functions that can see an entire segment are necessary to collect and forward RMON information. An RMON probe not only captures more data and processes it more than ordinary device agents, it can reduce traffic by storing intermediate results locally and forwarding them to an application on demand.

Agents And Managing Processes

SNMP managed entitieshubs, routers, database managers, toastersmust be outfitted with an agent that implements all the MIB objects relevant to them. The managing process must also be aware in advance of all the MIB objects implemented on entities it is expected to manage. Management consoles, such as HP OpenView, that communicate with many kinds of devices must allocate incremental resources for each different type of entityit's no wonder these platforms are resource intensive .

SNMP proper describes the packet layout (or protocol data unit) for messages between management agents and managing processes. In the first version of SNMP, there are only five possible messages. The GetRequest message with one or more object instances asks for the values of those object instances. The GetResponse message returns the object instances with their values. The GetNext-Request message provides an efficient method for the managing process to search tables of values. The SetRequest message writes a value to the agent, providing SNMP with the ability to configure and control entities remotely. (It's probably not necessary to mention that managed objects with an access attribute of "read-only" can't be Set.) SetRequests are acknowledged with GetResponse messages. Finally, Traps are messages initiated by the SNMP agent and sent to the managing process. They are not acknowledged .

SNMP has a crude and insecure mechanism for access control and authentication in the form of a "password" called a community name or community string. Among other problems, the community name is generally visible in unencrypted form in each SNMP packetshort work for any hacker with a protocol analyzer. With such severe potential threats, many network managers have been reluctant to implement the Set or write parts of SNMP, using it only to monitor devices and collect statistics. Of course, SNMP is a much less valuable technology as a result, and the potential for creating self-healing networks and other such marvels is cut off.

The people who developed SNMP were fully aware of the security problem and began working on it even before the first version of SNMP was standardized. In 1995, however, the standardization process for SNMP-2 broke down with competing approaches to a secure SNMP solution. One aspect of the problem was the fact that a secure SNMP-2 standard could not interoperate with the original SNMP because the original is irretrievably insecure.

SNMP-2 has other enhancements aside from securityit provides improved support for systems and applications management, as well as other extensions; it enables manager-to-manager communication, and therefore, a more distributed management model; and it makes retrieving tabular data more efficient with a new message type.

However, it seems clear that 1997 will pass without any vendor implementations, much less standard implementations, of secure SNMP. A potential savior is the possibility of adapting HTTP to transport management data. There are few criticisms of the SMI or the MIBs that structure management information. HTTP has at least two reasonably secure implementations , though the protocol itself has other problems. Under this plan, management agents would become a kind of specialized Web server and managing processes would exist as browsers. A series of valuable discussions on this subject is available from the Simple-Times electronic newsletter at www.simple-times.org. In fact, the Simple-Times electronic newsletter is a terrific source for any information having to do with SNMP.

This tutorial, number 102, by Steve Steinke, was originally published in the February 1997 issue of LAN Magazine/Network Magazine.