The Simple Network Management Protocol (SNMP) was developed to address the problems of Internet management. SNMP provides for effective monitoring and control of heterogeneous devices on both local and wide area networks. Since its introduction in 1988, SNMP has experienced widespread acceptance in the TCP/IP community, and it has spread to other communities as well. Figure 3-1 illustrates how SNMP fits into the Internet architecture.

For a list of Internet RFCs (Requests for Comment) and associated publications discussing SNMP, see E. SNMP Reference List.

The SNMP model of network management (see Figure 3-2) consists of the following constructs:

An agent is a node that resides on the network (such as a host, router, or terminal server), and is monitored, controlled, and configured by receiving and reacting to the commands sent by an NMS to manipulate the MIB. The NMS and agent communicate by sending SNMP messages. In addition, NMS receives unsolicited SNMP messages (traps) from agents.

There are three components to SNMP:

While a network management protocol could potentially require a large number of distinct commands (for example, add route, delete route, change interface address, examine address, and so on), SNMP casts all of its commands into a small handful of get and set commands which operate on a number of predefined objects. This means that an NMS exercises control over an agent by getting or setting the value of an object, rather than by issuing a specialized command to perform each possible action. For example, to shut down an interface, the NMS sets the interface status to the value off.

This paradigm separates the protocol from the objects managed by the protocol. The benefit is simplicity: there are a limited number of commands, yet there is extensibility. In other words, the number of objects managed by the protocol can grow larger as required by the application MIB.

The SNMP protocol uses UDP (User Datagram Protocol) at the transport layer and IP (Internet Protocol) at the network layer. The SNMP command (also known as a protocol data unit or PDU) implements requests, responses, and traps between the manager and the agent, as shown in Figure 3-3. SNMPv1 commands are listed in Table 3-1. The get, set, and response PDUs are formatted alike; the trap PDU contains different fields. SNMP communication is depicted in Figure 3-4: the manager sends requests to UDP port 161; the agent sends traps to UDP port 162.

Table 3-1:  SNMPv1/v2c Command Set

SNMPv1 is defined by the following documents: RFC 1155, RFC 1157, and RFC 1212. SNMP version 2c (SNMPv2c) is not yet officially standardized as of this writing, though an IETF draft is available. In short, SNMPv2c improves upon SNMPv1 in the following ways:

The Management Information Base (MIB) specifies a collection of management information on the agent that is controlled and monitored by an NMS. A MIB defines all the information an NMS can extract from the agent. For example, a MIB might specify that an agent will keep track of the number of errors that occur during the checksum of TCP packets.

As stated previously, the objects in the MIB are separate from the actual SNMP protocol. This allows the MIB information stored in a particular agent to be extended and customized without modification to the protocol.

The MIB that resides in an agent may be made up of several MIB modules. There are standard MIB modules and custom MIB modules. MIB-II is a standard MIB module that contains information about the Internet network protocol suite (TCP, UDP, IP, ICMP, and so on). For an example of the development of custom MIB module, see 6.3 Compile-time MIB Extensions.

For more information on available standard MIBs, see E. SNMP Reference List. To explore the standard MIBs included with this component, examine the contents of the directory $WIND_BASE/target/src/snmpv1/mibs/*.mib (also see 4.2.3 $WIND_BASE/target/src/snmpv1/mibs/).

Where the MIB defines the specific network management variables stored in an agent, the Structure of Management Information (SMI) specifies how these MIB variables are defined and identified. For example, the SMI places restrictions on the MIB variable types; only a handful of types are defined (integer, octet string, and so on).

The names used for MIB variables are taken from the object identifier (OID) name space administered by the ISO and CCITT. The name space is hierarchical, and authority for each part of the name space is subdivided at each level. Figure 3-5 illustrates the object identifier name space hierarchy. 

Objects are named according to the sequence of the numeric values on the nodes in the path from the root to the object. The string names provide a format more easily read by users. For example:

MIB-II is		1.3.6.1.2.1		iso.org.dod.internet.mgmt.mib
WRS is		1.3.6.1.4.1.731		iso.org.dod.internet.private.enterprises.WRS