TCP/IP Protocols (25) -- SNMP: Simple Network Management Protocol

As the number of networks within an organization grows, along with the diversity of systems comprising this internet (routers from various vendors, hosts with embedded router functionality, terminal servers, etc.), managing all these systems within a coherent framework becomes important.

Network management of a TCP/IP internet consists of network management stations (managers) communicating with network elements. The network elements can be anything that runs the TCP/IP protocol suite: hosts, routers, X terminals, terminal servers, printers, and so on. The software in the network element that runs the management software is called the agent. Management stations are normally workstations with color monitors that graphically display relevant facts about the elements being monitored (which links are up and down, volume of traffic across various links over time, etc.).

"The communication can be two way: the manager asking the agent for a specific value ("how many ICMP port unreachables have you generated?"), or the agent telling the manager that something important happened ("an attached interface has gone down"). Also, the manager should be able to set variables in the agent ("change the value of the default IP TTL to 64"), in addition to reading variables from the agent. TCP/IP network management consists of three pieces.

1. A Management Information Base (MIB) that specifies what variables the network elements maintain (the information that can be queried and set by the manager). RFC 1213 [McCloghrie and Rose 1991] defines the second version of this, called MIB-II.

2. A set of common structures and an identification scheme used to reference the variables in the MIB. This is called the Structure of Management Information (SMI) and is specified in RFC 1155 [Rose and McCloghrie 1990]. For example, the SMI specifies that a Counter is a nonnegative integer that counts from 0 through 4,294,967,295 and then wraps around to 0.

3. The protocol between the manager and the element, called the Simple Network Management Protocol (SNMP). RFC 1157 [Case et al. 1990] specifies the protocol. This details the format of the packets exchanged. Although a wide variety of transport protocols could be used, UDP is normally used with SNMP.

These RFCs define what is now called SNMPv1, or just SNMP, which is the topic of this chapter. During 1993 additional RFCs were published specifying SNMP Version 2 (SNMPv2).

Protocol

SNMP defines only five types of messages that are exchanged between the manager and agent.

1. Fetch the value of one or more variables: the get-request operator.

2. Fetch the next variable after one or more specified variables: the get-next-request operator.

3. Set the value of one or more variables: the set-request operator.

4. Return the value of one or more variables: the get-response operator. This is the message returned by the agent to the manager in response to the get-request, get-next-request, and set-request operators.

5. Notify the manager when something happens on the agent: the trap operator.

The first three messages are sent from the manager to the agent, and the last two are from the agent to the manager. (We'll refer to the first three as the get, get-next, and set operators.)

Since four of the five SNMP messages are simple request-reply protocols (the manager sends a request, the agent sends back a reply) SNMP uses UDP. This means that a request from the manager may not arrive at the agent, and the agent's reply may not make it back to the manager. The manager probably wants to implement a timeout and retransmission.

The manager sends its three requests to UDP port 161. The agent sends traps to UDP port 162. By using two different port numbers, a single system can easily run both a manager and an agent.

The format of the five SNMP messages:

IP header

UDP header

version (0)

community

PDU type (0-3)

request ID

error status (0-5)

error index

name

value

name

value

...

20 bytes

8 bytes

IP header

UDP header

version (0)

community

PDU type (4)

enterprise

agent addr

trap type (0-6)

specific code

timestamp

name

value

...

20 bytes

8 bytes

The encoding used for the SNMP message-called ASN.1 and BER, varies depending on the type of variable and its value.

The version is 0. This value is really the version number minus one, as the version of SNMP that we describe is called SNMPv1.

PDU type	Name
0	get-request
1	get-next-request
2	set-request
3	get-response
4	trap

The community is a character string that is a cleartext password between the manager and agent. A common value is the 6-character string public.

For the get, get-next, and set operators, the request ID is set by the manager, and returned by the agent in the get-response message. We've seen this type of variable with other UDP applications. It lets the client (the manager in this case) match the responses from the server (the agent) to the queries that the client issued. "This field also allows the manager to issue multiple requests to one or more agents, and then be able to sort out the returned replies.

The error status is an integer returned by the agent specifying an error:

error status	Name	Description
0	noError	all is OK
1	tooBig	agent could not fit reply into a single SNMP message
2	noSuchName	operation specified a nonexistent variable
3	badValue	a set operation specified an invalid value or syntax
4	readonly	manager tried to modify a read-only variable
5	genErr	some other error

If an error occurred, the error index is an integer offset specifying which variable was in error. It is set by the agent only for the noSuchName, badValue, and readonly errors.

A list of variable names and values follows in the get, get-next, and set requests. The value portion is ignored for the get and get-next operators.

For the trap operator (a PDU type of 4), the format of the SNMP message changes.

Structure of Management Information

SNMP uses only a few different types of data. In this section we'll look at those data types, without worrying about how the data is actually encoded (that is, the bit pattern used to store the data).

1. INTEGER. Some variables are declared as an integer with no restrictions (e.g., the MTU of an interface), some are defined as taking on specific values (e.g., the IP forwarding flag is 1 if forwarding is enabled or 2 if forwarding is disabled), and others are defined with a minimum and maximum value (e.g., UDP and TCP port numbers are
between 0 and 65535).

2. OCTET STRING. A string of 0 or more 8-bit bytes. Each byte has a value between 0 and 255. In the BER encoding used for this data type and the next, a count of the number of bytes in the string precedes the string. These strings are not null-terminated strings.

3. DisplayString. A string of 0 or more 8-bit bytes, but each byte must be a character from the NVT ASCII set. All variables of this type in the MIB-II must contain no more than 255 characters. (A O-length string is OK.)

4. OBJECT IDENTIFIER.

5. NULL. This indicates that the corresponding variable has no value. It is used, for example, as the value of all the variables in a get or get-next request, since the values are being queried, not set.

6. lpAddress. An OCTET STRING of length 4, with 1 byte for each byte of the IP address.

7. PhysAddress. An OCTET STRING specifying a physical address (e.g., a 6-byte Ethernet address).

8. Counter. A nonnegative integer whose value increases monotonically from 0 to 232-1 (4,294,967,295), and then wraps back to 0.

9. Gauge. A nonnegative integer between 0 and 2³² -1, whose value can increase or decrease, but latches at its maximum value. That is, if the value increments to 2³² -1, it stays there until reset. The MIB variable tcpCurrEstab is an example: it is the number of TCP connections currently in the ESTABLISHED or CLOSE_WAIT state.

10. TimeTicks. A counter that counts the time in hundredths of a second since some epoch. Different variables can specify this counter from a different epoch, so the epoch used for each variable of this type is specified when the variable is declared in the MIB. For example, the variable sysUpTime is the number of hundredths of a second that the agent has been up.

11. SEQUENCE. This is similar to a structure in the C programming language. For example, we'll see that the MIB defines a SEQUENCE named UdpEntry containing information about an agent's active UDP end points. (By "active" we mean ports currently in use by an application.) Two entries are in the structure: 1. udpLocalAddress, of type lpAddress, containing the local IP address. 2. udpLocalPort, of type INTEGER, in the range 0 through 65535, specifying the local port number.

12. SEQUENCE OF. This is the definition of a vector, with all elements having the same data type. If each element has a simple data type, such as an integer, then we have a simple vector (a one-dimensional array). But we'll see that SNMP uses this data type with each element of the vector being a SEQUENCE (structure). We can then think of it as a two-dimensional array or table.

Object Identifiers

An object identifier is a data type specifying an authoritatively named object. By "authoritative" we mean that these identifiers are not assigned randomly, but are allocated by some organization that has responsibility for a group of identifiers.

An object identifier is a sequence of integers separated by decimal points. These integers traverse a tree structure, similar to the DNS or a Unix filesystem. There is an unnamed root at the top of the tree where the object identifiers start. (This is the same direction of tree traversal that's used with a Unix filesystem.)

Introduction to the Management Information Base

The Management Information Base, or MIB, is the database of information maintained by the agent that the manager can query or set. We describe what's called MIB-II, specified in RFC 1213 [McCloghrie and Rose 1991].

The MIB is divided into groups named system, interfaces, at (address translation), ip, and so on.

The UDP group is a simple group with only a few variables and a single table.

Instance Identification

Every variable in the MIB must be identified when SNMP is referencing it, to fetch or set its value. First, only leaf nodes are referenced. SNMP does not manipulate entire rows or columns of tables.

Simple variables are referenced by appending ".0" to the variable's object identifier. For example, object identifier 1.3.6.1.2.1.7.1 is referenced as 1.3.6.1.2.1.7.1.0.

Instance identification of table entries is more detailed.  One or more indexes are specified in the MIB for each table. For the UDP listener table, the MIB defines the index as the combination of the two variables udpLocalAddress, which is an IP address, and udpLocalPort, which is an integer.

Traps

It's also possible for the agent to send a trap to the manager, to indicate that something has happened on the agent that the manager might want to know about. Traps are sent to UDP port 162 on the manager.