Since its introduction in 1988, the Simple Network Management Protocol (SNMP) has become the de facto network management protocol on TCP/IP-based networks. The IETF created SNMP to allow remote management of IP-based devices using a standardized set of operations. It is now widely supported by servers, printers, hubs, switches, modems, UPS systems, and, of course, Cisco routers.
The SNMP set of standards defines much more than a communication protocol used for management traffic. The standards also define how management data should be accessed and stored, as well as the entire distributed framework of SNMP agents and servers. The IETF has officially recognized SNMP as a fully standard part of the IP protocol suite. The original SNMP definition is documented in RFC 1157.
In 1993, SNMP Version 2 (SNMPv2) was created to address a number of functional deficiencies that were apparent in the original protocol. The added and improved features included better error handling, larger data counters (64-bit), improved efficiency (get-bulk transfers), confirmed event notifications (informs), and, most notably, security enhancements. Unfortunately, SNMPv2 did not become widely accepted because the IETF was unable to come to a consensus on the SNMP security features.
So a revised edition of SNMPv2 was released in 1996. It is discussed in RFCs 1905, 1906, and 1907 and included all of the proposed enhancements, except for the security facility. The IETF refers to this new version as SNMPv2c, and it uses the same insecure security model as SNMPv1. This model relies on passwords called community strings that are sent over the network as clear text. SNMPv2c never enjoyed widespread success throughout the IP community. Consequently, most organizations continue to use SNMPv1. The IETF recently announced that SNMPv3 would be the new standard, with SNMPv1, SNMPv2, and SNMPv2c being considered purely historical.
We should note in passing that Cisco's IOS supported SNMPv2 until Version 11.2(6)F, when Cisco began supporting SNMPv2c. Cisco continues to support SNMPv2c in every IOS version beginning with 11.2(6)F. In addition, every version of IOS has supported SNMPv1 since the earliest releases.
The compromise that became SNMPv2c left the management protocol without satisfactory security features. So, in 1998, the IETF began working on SNMPv3, which is defined in RFCs 25712575. Essentially, SNMPv3 is a set of security enhancements to be used in conjunction with SNMPv2c. This means that SNMPv3 is not a standalone management protocol and does not replace SNMPv2c or SNMPv1.
SNMPv3 provides a secure method for accessing devices using authentication, message integrity, and encryption of SNMP packets throughout the network. We have included a recipe describing how to use the SNMPv3 security enhancements (see Recipe 17.22). Table 17-1 lists the three supported versions of SNMP and highlights their security capabilities.
| Version | Authentication | Encryption | Description |
|---|---|---|---|
| v1 | Community strings | None | Trivial authentication. Packets sent in clear text. |
| v2c | Community strings | None | Trivial authentication. Packets sent in clear text. |
| v3(noAuthNoPriv) | Username | None | Trivial authentication. Packets sent in clear text. |
| v3(authNoPriv) | SHA or MD5-encrypted passphrase | None | Strong authentication. Packets sent in clear text. |
| v3(authPriv) | SHA or MD5-encrypted passphrase | DES, 3DES, or AES | Strong authentication. Packets are encrypted. |
SNMP Management Model
SNMP defines two main types of entities, managers and agents. A manager is a server that runs network management software that is responsible for a particular network. These servers are commonly referred to as Network Management Stations (NMS). There are several excellent commercial NMS platforms on the market. Throughout this book, we refer to the freely distributed NET-SNMP system as a reference NMS.
An agent is an embedded piece of software that resides on a remote device that you wish to manage. In fact, almost every IP capable device provides some sort of built-in SNMP agent. The agent has two main functions. First, the agent must listen for incoming SNMP requests from the NMS and respond appropriately. And second, the agent must monitor internal events and create SNMP traps to alert the NMS that something has happened. This book will focus mainly on how to configure the router's agent.
Usually, the NMS is configured to poll all of the key devices in the network periodically using SNMP Get requests. This is a UDP packet sent to the agent on the well-known SNMP port 161. The SNMP Get request prompts the remote device to respond with one or more pieces of relevant operating information.
However, because there could be hundreds or thousands of remote devices, it is often not practical to poll a particular remote device more often than once every few minutes (and in many networks, you are lucky if you can poll each device more than a few times per hour). On a schedule like this, it is possible for a remote device to suffer a serious problem, and possibly even crash and reboot in between polls from the NMS. So, on the next poll, the NMS will see everything operating normally and never know that it completely missed a catastrophe.
Therefore, an SNMP agent also has the ability to send information using an SNMP Trap without having to wait for a poll. A trap is an unsolicited piece of information, usually representing a problem situation (although some traps are more informational in nature). Traps are UDP packets sent from the agent to the NMS on the other well-known SNMP port number, 162. There are many different types of traps that an agent can send, depending on what type of equipment it manages. Some traps represent noncritical issues. It is often up to the network administrator to decide which types of traps will be useful.
It is important to remember the NMS does not acknowledge traps. Since traps are often sent to report network problems, it is not uncommon to for trap reports to get lost and never make it to the NMS. In many cases, this is acceptable because the trap represents a transient problem that the NMS discovers by other means if this trap is not delivered. However, critical information can be lost when a trap is not delivered.
To address this shortcoming, SNMPv2c and SNMPv3 include another type of packet called an SNMP Inform. This is nearly identical to a standard trap, except that the SNMP agent will wait for an acknowledgement. If the agent does not receive an acknowledgement within a certain amount of time, it will attempt to retransmit the inform. Informs also use UDP port 162.
SNMP informs not common today because SNMP Version 2c was never widely adopted. However, SNMP Version 3 also includes informs. Because SNMPv3 promises to become the mainstream SNMP protocol, it seems inevitable that enhancements like SNMP Informs will start to be more common.
MIBs and OIDs
SNMP uses a special tree structure called a Management Information Base (MIB) to organize the management data. People will often talk about different MIBs, such as the T1 MIB or an ATM MIB. In fact, these are all really just branches or extensions of the same global MIB tree structure. However, the relative independence of these different branches makes it convenient to talk this way.
A particular SNMP agent will only care about those few MIB branches that are relevant to the particular remote device this agent run on. If the device doesn't have any T1 interfaces, then the agent doesn't need to know anything about the T1 branch of the global MIB tree. Similarly, the NMS for a network that contains no ATM doesn't need to be able to resolve any of the variables in the ATM branches of the MIB tree.
The MIB tree structure is defined by a long sequence of numbers separated by dots, such as .1.3.6.1.2.1.1.4.0. This number is called an Object Identifier (OID). Since we will be working with OID strings throughout this chapter, it is worthwhile to take a brief review of how they work and what they mean.
The OID is a numerical representation of the MIB tree structure. Each digit represents a node in this tree structure. The trunk of the tree is on the left and the leaves are on the right. In the example string, .1.3.6.1.2.1.1.4.0, the first digit, .1, signifies that this variable is part of the MIB that is administered by the International Standards Organization (ISO). There are other nodes at this top level of the tree. The International Telephone and Telegraph Consultative Committee (CCITT) administers the .0 tree structure. And the ISO and CCITT jointly administer .2.
The first node under the ISO MIB tree of this example is .3. The ISO has allocated this node for all other organizations. The U.S. Department of Defense (DOD) is designated by the branch number .6. The DOD, in turn, has allocated branch number .1 for the Internet Activities Board (IAB). So just about every SNMP MIB variable you will ever see will begin with .1.3.6.1.
There are four commonly used subbranches under the IAB (also called simply "internet") node. These are designated directory (1), mgmt (2), experimental (3), and private (4). The directory node is seldom used in practice. The mgmt node is used for all IETF standard MIB extensions, which are documented in RFCs. This would include, for example, the T1 and ATM MIB structures mentioned earlier. However, it would not include any vendor-specific variables, such as the CPU utilization on a Cisco router. SNMP protocol and application developers use the experimental subtree to hold data that is not yet standard. This allows you to use experimental MIBs in a production network without fear of causing conflicts. And, finally, the private subtree contains vendor-specific MIB variables.
Before returning to the example, we want to take a brief detour down the private tree, because a lot of our examples in this book will include Cisco-specific MIB variables. A good example of a Cisco MIB variable is .1.3.6.1.4.1.9.2.1.8.0, which gives the amount of free memory in a Cisco router. There is only one subtree under the private node, and it is called enterprises, .1.3.6.1.4.1. Of the hundreds of registered owners of private MIB trees, Cisco is number 9, so all Cisco-specific MIB extensions begin with .1.3.6.1.4.1.9.
Referring again to the previous example string, .1.3.6.1.2.1.1.4.0, you can see that this represents a variable in the mgmt subtree, .1.3.6.1.2. The next digit is .1 here, which represents an SNMP MIB variable.
The following digit, .1, refers to a specific group of variables, which in the case of mgmt variables would be defined by an RFC. In this particular case, the value .1 refers to the system MIB, which is detailed in RFC 1450.
From this level down, a special naming convention is adopted to help you to remember which MIB you are looking at. The names of every variable under the system node begin with "sys". They are sysDescr (1), sysObjectID (2), sysUpTime (3), sysContact (4), sysName (5), sysLocation (6), sysServices (7), sysORLastChange (8), and sysORTable (9). You can find detailed descriptions of what all of these mean in RFC 1450. In fact, reading through MIB descriptions is an excellent way of understanding not only the hierarchical structure of the MIB, but also extremely useful when you are trying to decide what information you can and should be extracting from your equipment.
In the example string, .1.3.6.1.2.1.1.4.0, the value is .4, for sysContact. The following .0 just tells the agent to send the contents of this node, rather than treating it as the root of further subtrees. So the OID string uniquely identifies a single piece of information, which in this case is the contact information for the device.