Simple Network Management Protocol

The purpose of a protocol is to facilitate communication, and whenever a particular type of communication has distinctive and definable characteristics, you are likely to find a corresponding protocol. Simple Network Management Protocol (SNMP) is a protocol designed for managing and monitoring remote devices on a network. SNMP supports a system that enables a single network administrator operating from a single workstation to remotely manage and monitor computers, routers, and other network devices.

Figure 21.1 shows the principle components of the SNMP architecture:

• Network monitor A management console, sometimes called a manager or a Network Management Console (NMS), provides a central location for managing devices on the network. The network monitor is typically an ordinary computer with the necessary SNMP management software.

• Nodes Devices on the network.

• Community A group of nodes in a common management framework.

Figure 21.1. An SNMP community consists of one or more network monitors and a collection of nodes.

As you've learned elsewhere in this book, a protocol provides a scheme for communication, but the actual interaction occurs between applications running on the communicating devices. In the case of SNMP, a program called an agent runs on the remote node and communicates with the management software running on the network monitor (see Figure 21.2).

Figure 21.2. An agent program running on the remote node sends information on the node to the network monitor and receives requests for changes to configuration settings.

The monitor and the agent use the SNMP protocol to communicate with each. SNMP uses UDP ports 161 and 162. Older versions of SNMP did not require any form of user logon security. Security was provided by the community name, which is referred to as the community string. (You had to know the community string in order to connect.) In some cases, you could also configure the agent to only receive data from specific IP addresses. This type of security, however, is considered weak by contemporary standards. The most recent version of SNMP, SNMP v3, addresses these concerns, providing authentication, privacy, and better overall security for the system.

You might be wondering what the monitor and the agent communicate about. What kind of data passes between the monitor and the agent through SNMP? As you'll learn in the next section, SNMP defines a vast collection of management parameters. The network monitor uses the parameters of this Management Information Base (MIB) to request information from the agent and change configuration settings.

The SNMP Address Space

The SNMP process is predicated on both the monitor and agent software being capable of exchanging information regarding specific addressable locations within the MIB. The MIB, shown in Figure 21.3, allows the monitor and agent to exchange information accurately and unambiguously. Both the monitor and the agent require identical MIB structures, because they must be capable of uniquely identifying a specific unit of information.

Figure 21.3. A small portion of the MIB.

The MIB is a hierarchical address space that includes a unique address for each piece of information. Note that MIB addresses aren't like network addresses in that they don't represent a location or an actual device. The MIB is really a collection of parameters arranged hierarchically into an address space. This hierarchical address arrangement ensures that all SNMP devices refer to a specific setting the same way. This approach also allows for convenient decentralization. For instance, a specific vendor can define the MIB settings (often referred to simply as MIBs) that apply to the vendor's products, or a standards organization can manage the part of the MIB tree devoted to its standard. The MIB uses dotted notation to identify each unique address within the MIB object.

By the Way

The MIB has been described in several RFCs, including RFC 1158 and RFC 1213. You'll find the official description of SNMP in RFC 1157. The latest version, SNMP v3, is described in RFC 2570 and a number of other RFCs.

The majority of the addressable locations within the MIB refer to counters, which are obviously numeric. An example of a counter is ipForwarding, shown in Figure 21.3, or ipInReceives (not shown), which counts the number of inbound IP datagrams received since either the networking software was started or the counter was last reset.

MIB information could be in any of several forms: numeric, textual, IP addresses, and so on. Another example of MIB configuration information is ipDefaultTTL. The ipDefaultTTL setting holds the numeric value of the TTL (Time To Live) parameter inserted into every IP datagram that originates on a computer.

The MIB structure is addressed by always starting at the root and progressing down through the hierarchy until you have uniquely identified the setting you want to read. For example, to address the ipDefaultTTL and ipInReceives MIBs, the SNMP monitor would send the following MIB addresses to the SNMP agent:

 .iso.org.dod.internet.mgmt.mib.ip.ipDefaultTTL .iso.org.dod.internet.mgmt.mib.ip.ipInReceives 

Every location of the MIB tree also has an equivalent numeric address. You can refer to a MIB by either its alphanumeric string or by its numeric address. In fact, it's the numeric form that the network monitor uses when querying information from the agent:

 .1.3.6.1.2.1.4.2 .1.3.6.1.2.1.4.3 

The MIB address provides a common nomenclature to ensure that the monitor and the agent can reliably refer to specific parameters. These MIB parameters are then included in commands, as described in the next section.

SNMP Commands

The network monitoring agent software responds to three commands: get, getnext, and set. These commands perform the following functions:

• get The get command instructs the agent to read and return one specific unit of information from the MIB.

• getnext The getnext command instructs the agent to read and return the next sequential unit of information from the MIB. This command could be used to read a table of values, for example.

• set The set command instructs the agent to set a configurable parameter or to reset an object such as a network interface or a specific counter.

SNMP software actually works in several different ways, depending on the needs of the network administrator. Different types of SNMP behavior are described in the following list:

• A network monitor agent always operates in a query/response manner where it can receive requests from and send responses to the monitor. The agent receives either a get or getnext command and returns the information from one addressable location.

• Although optional, agents are often configured to send unsolicited messages to the network monitor when unusual events occur. These unsolicited messages are known as trap messages or traps; they occur when the agent software traps some unusual occurrence.

  For example, SNMP agent software usually operates in a mode where it monitors for established thresholds to be exceeded. These thresholds are established using the set command. In the event that a threshold is exceeded, the agent traps the occurrence and then constructs and sends an unsolicited message to the network monitor identifying the IP address of the machine where the trap occurred, as well as which threshold was exceeded.

• Agents can also receive requests from the monitor to perform certain actions, such as to reset a specific port on a router or to set the threshold levels that are used in trapping events. Again, the set command is used for setting configurable parameters or resetting counter or interfaces.

The following example illustrates query and response commands used by SNMP. This example uses a diagnostic utility called snmputil, which allows a technician to simulate a monitor. Through the utility, a technician can issue commands to the agent. In this case, the agent is located on a computer with an IP address of 192.59.66.200, and the agent is a member of a community named public. Notice the .0 at the end of the first two commands; this is used as a suffix when reading simple variables such as counters.

 D:\>snmputil get 192.59.66.200 public .1.3.6.1.2.1.4.2.0 Variable = ip.ipDefaultTTL.0 Value    = INTEGER - 128 D:\>snmputil getnext 192.59.66.200 public .1.3.6.1.2.1.4.2.0 Variable = ip.ipInReceives.0 Value    = Counter - 11898 

Watch Out!

The default community name on many SNMP systems is public. The admin in this example should have changed the name to something else. You give an attacker a head start when you use a default name.

SNMP is useful to network administrators, but it is not perfect. Some of the shortcomings of SNMP are described in the following list:

• Cannot see lower layers SNMP resides at the Application layer above UDP, so it cannot see what is happening at the lowest layers within the protocol stack, such as what is happening at the Network Access layer.

• Requires an operational protocol stack A fully operational TCP/IP stack is required for an SNMP monitor and agent to communicate. If you're having network problems that prevent the stack from operating correctly, SNMP cannot help troubleshoot the problem.

• Can generate heavy network traffic The query response mechanism used by SNMP causes a great deal of network traffic. Although unsolicited traps are sent when significant events occur, in actuality network monitors generate a constant amount of network traffic as they query agents for specific information.

• Provides too much data and too little information With the literally thousands of address locations within an MIB, you can retrieve many small pieces of information. However, it requires a powerful management console to analyze these minute details and to be capable of providing useful analysis of what is occurring on a specific machine.

• Provides view of the machine but not the network SNMP is designed to provide information on a specific device. You can't see what is occurring on the network segment.