Essential SNMP | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In today's complex network of routers, switches, and servers, it can seem like a daunting task to manage all the devices on your network and make sure they're not only up and running but also performing optimally. This is where the Simple Network Management Protocol (SNMP) can help. SNMP was introduced in 1988 to meet the growing need for a standard for managing Internet Protocol (IP) devices. SNMP provides its users with a "simple" set of operations that allows these devices to be managed remotely.

This book is aimed toward system administrators who would like to begin using SNMP to manage their servers or routers, but who lack the knowledge or understanding to do so. We try to give you a basic understanding of what SNMP is and how it works; beyond that, we show you how to put SNMP into practice, using a number of widely available tools. Above all, we want this to be a practical book—a book that helps you keep track of what your network is doing.

This chapter introduces SNMP, network management , and change management. Obviously, SNMP is the focus of this book, but having an understanding of general network management concepts will make you better prepared to use SNMP to manage your network.

The core of SNMP is a simple set of operations (and the information these operations gather) that gives administrators the ability to change the state of some SNMP-based device. For example, you can use SNMP to shut down an interface on your router or check the speed at which your Ethernet interface is operating. SNMP can even monitor the temperature on your switch and warn you when it is too high.

SNMP usually is associated with managing routers, but it's important to understand that it can be used to manage many types of devices. While SNMP's predecessor, the Simple Gateway Management Protocol (SGMP) , was developed to manage Internet routers, SNMP can be used to manage Unix systems, Windows systems, printers, modem racks, power supplies, and more. Any device running software that allows the retrieval of SNMP information can be managed. This includes not only physical devices but also software, such as web servers and databases.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The core of SNMP is a simple set of operations (and the information these operations gather) that gives administrators the ability to change the state of some SNMP-based device. For example, you can use SNMP to shut down an interface on your router or check the speed at which your Ethernet interface is operating. SNMP can even monitor the temperature on your switch and warn you when it is too high.

SNMP usually is associated with managing routers, but it's important to understand that it can be used to manage many types of devices. While SNMP's predecessor, the Simple Gateway Management Protocol (SGMP) , was developed to manage Internet routers, SNMP can be used to manage Unix systems, Windows systems, printers, modem racks, power supplies, and more. Any device running software that allows the retrieval of SNMP information can be managed. This includes not only physical devices but also software, such as web servers and databases.

Another aspect of network management is network monitoring ; that is, monitoring an entire network as opposed to individual routers, hosts, and other devices. Remote Network Monitoring (RMON ) was developed to help us understand how the network itself is functioning, as well as how individual devices on the network are affecting the network as a whole. It can be used to monitor not only LAN traffic, but WAN interfaces as well. We discuss RMON in more detail later in this chapter and in Chapter 2.

The Internet Engineering Task Force (IETF) is responsible for defining the standard protocols that govern Internet traffic, including SNMP. The IETF publishes Requests for Comments (RFCs), which are specifications for many protocols that exist in the IP realm. Documents enter the standards track first as

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SNMP is really about network management. Network management is a discipline of its own, but before learning about the details of SNMP in Chapter 2, it's helpful to have an overview of network management itself.

What is network management? Network management is a general concept that employs the use of various tools, techniques, and systems to aid human beings in managing various devices, systems, or networks. Let's take SNMP out of the picture right now and look at a model for network management called FCAPS, or Fault Management, Configuration Management, Accounting Management, Performance Management, and Security Management. These conceptual areas were created by the International Organization for Standardization (ISO) to aid in the understanding of the major functions of network management systems. Let's briefly look at each of these now.

The goal of fault management is to detect, log, and notify users of systems or networks of problems. In many environments, downtime of any kind is not acceptable.

Fault management dictates that these steps for fault resolution be followed:

Isolate the problem by using tools to determine symptoms.
Resolve the problem.
Record the process that was used to detect and resolve the problem.

While step 3 is important, it is often not used. Neglecting step 3 has the unwanted effect of causing new engineers to follow steps 1 and 2 in the dark when they could have consulted a database of troubleshooting tips.

The goal of configuration management is to monitor network and system configuration information so that the effects on network operation of various versions of hardware and software elements can be tracked and managed.

Any system may have a number of interesting and pertinent configuration parameters that engineers may be interested in capturing, including:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Being able to apply the concepts of network management is as important as learning how to use SNMP. This section of the chapter provides insights into some of the issues surrounding network management.

The endeavor of network management involves solving a business problem through an implementation of some sort. A business case is developed to understand the impact of implementing some sort of task or function. It looks at how, for example, network administrators do their day-to-day jobs. The basic idea is to reduce costs and increase effectiveness. If the implementation doesn't save a company any money while providing more effective services, there is almost no need to implement a given solution.

Before applying management to a specific service or device, you must understand the four possible levels of activity and decide what is appropriate for that service or device:

Inactive: No monitoring is being done, and, if you did receive an alarm in this area, you would ignore it.
Reactive: No monitoring is being done; you react to a problem if it occurs.
Interactive: You monitor components but must interactively troubleshoot them to eliminate side-effect alarms and isolate a root cause.
Proactive: You monitor components, and the system provides a root-cause alarm for the problem at hand and initiates predefined automatic restoral processes where possible to minimize downtime.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Change management deals with, well, managing change. In other words, you need to plan for both scheduled and emergency changes to your network. Not doing so can cause networks and systems to be unreliable at best and can upset the very people you work for at worst. The following sections provide a high-level overview of change management techniques. The following techniques are recommended by Cisco. See the end of this section for the URL to this paper and others on the topic of network management.

Change planning is a process that identifies the risk level of a change and builds change planning requirements to ensure that the change is successful. The key steps for change planning are as follows:

Assign all potential changes a risk level prior to scheduling the change.
Document at least three risk levels with corresponding change planning requirements. Identify risk levels for software and hardware upgrades, topology changes, routing changes, configuration changes, and new deployments. Assign higher risk levels to nonstandard add, move, or change types of activity.
The high-risk change process you document needs to include lab validation, vendor review, peer review, and detailed configuration and design documentation.
Create solution templates for deployments affecting multiple sites. Include information about physical layout, logical design, configuration, software versions, acceptable hardware chassis and modules, and deployment guidelines.
Document your network standards for configuration, software version, supported hardware, and DNS. Additionally, you may need to document things like device naming conventions, network design details, and services supported throughout the network.

Change management is a process that approves and schedules the change to ensure the correct level of notification with minimal user impact. The key steps for change management are as follows:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Getting a handle on SNMP may seem like a daunting task. The RFCs provide the official definition of the protocol, but they were written for software developers, not network administrators, so it can be difficult to extract the information you need from them. Fortunately, many online resources are available. A good place to look is the SimpleWeb (http://www.simpleweb.org). SNMP Link (http://www.SNMPLink.org) is another good site for information. The Simple Times, an online publication devoted to SNMP and network management, is also useful. You can find all the issues ever published at http://www.simple-times.org. SNMP Research is a commercial SNMP vendor. Aside from selling advanced SNMP solutions, its web site contains a good amount of free information about SNMP. The company's web site is http://www.snmp.com.

Another great resource is Usenet news. The newsgroup most people frequent is comp.dcom.net-management. Another good newsgroup is comp.protocols.snmp. Groups such as these promote a community of information sharing, allowing seasoned professionals to interact with individuals who are not as knowledgeable about SNMP or network management. Google has a great interface for searching Usenet news group at http://groups.google.com.

There is an SNMP FAQ, available in two parts at http://www.faqs.org/faqs/snmp-faq/part1/ and http://www.faqs.org/faqs/snmp-faq/part2/.

Cisco has some very good papers on network management, including "Network Management Basics" (http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/nmbasics.htm) and "Change Management," from which Figure 1-2 and Figure 1-3 were drawn. Also, Douglas W. Stevenson's article, "Network Management: What It Is and What It Isn't," available at http://www.itmweb.com/essay516.htm, provides important background material for all students of network management.

With that background in mind, Chapter 2 delves much deeper into the details of SNMP.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, we start to look at SNMP in detail, specifically covering features found in SNMPv1 and SNMPv2 (we'll allude to SNMPv3 occasionally but we describe its features in detail in Chapter 3). By the time you finish this chapter, you should understand how SNMP sends and receives information, what SNMP communities are, and how to read MIB files. We'll also look in more detail at the three MIBs that were introduced in Chapter 1, namely MIB-II, Host Resources, and RMON.

SNMP uses the User Datagram Protocol (UDP) as the transport protocol for passing data between managers and agents. UDP, defined in RFC 768, was chosen over the Transmission Control Protocol (TCP) because it is connectionless; that is, no end-to-end connection is made between the agent and the NMS when datagrams (packets) are sent back and forth. This aspect of UDP makes it unreliable since there is no acknowledgment of lost datagrams at the protocol level. It's up to the SNMP application to determine if datagrams are lost and retransmit them if it so desires. This is typically accomplished with a simple timeout. The NMS sends a UDP request to an agent and waits for a response. The length of time the NMS waits depends on how it's configured. If the timeout is reached and the NMS has not heard back from the agent, it assumes the packet was lost and retransmits the request. The number of times the NMS retransmits packets is also configurable.

At least as far as regular information requests are concerned, the unreliable nature of UDP isn't a real problem. At worst, the management station issues a request and never receives a response. For traps, the situation is somewhat different. If an agent sends a trap and the trap never arrives, the NMS has no way of knowing that it was ever sent. The agent doesn't even know that it needs to resend the trap because the NMS is not required to send a response back to the agent acknowledging receipt of the trap.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SNMP uses the User Datagram Protocol (UDP) as the transport protocol for passing data between managers and agents. UDP, defined in RFC 768, was chosen over the Transmission Control Protocol (TCP) because it is connectionless; that is, no end-to-end connection is made between the agent and the NMS when datagrams (packets) are sent back and forth. This aspect of UDP makes it unreliable since there is no acknowledgment of lost datagrams at the protocol level. It's up to the SNMP application to determine if datagrams are lost and retransmit them if it so desires. This is typically accomplished with a simple timeout. The NMS sends a UDP request to an agent and waits for a response. The length of time the NMS waits depends on how it's configured. If the timeout is reached and the NMS has not heard back from the agent, it assumes the packet was lost and retransmits the request. The number of times the NMS retransmits packets is also configurable.

At least as far as regular information requests are concerned, the unreliable nature of UDP isn't a real problem. At worst, the management station issues a request and never receives a response. For traps, the situation is somewhat different. If an agent sends a trap and the trap never arrives, the NMS has no way of knowing that it was ever sent. The agent doesn't even know that it needs to resend the trap because the NMS is not required to send a response back to the agent acknowledging receipt of the trap.

The upside to the unreliable nature of UDP is that it requires low overhead , so the impact on your network's performance is reduced. SNMP has been implemented over TCP, but this is more for special-case situations in which someone is developing an agent for a proprietary piece of equipment. In a heavily congested and managed network, SNMP over TCP is a bad idea. It's also worth realizing that TCP isn't magic and that SNMP is designed for working with networks that are in trouble—if your network never failed, you wouldn't need to monitor it. When a network is failing, a protocol that tries to get the data through but gives up if it can't is almost certainly a better design choice than a protocol that floods the network with retransmissions in its attempt to achieve reliability.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SNMPv1 and SNMPv2 use the notion of communities to establish trust between managers and agents. An agent is configured with three community names : read-only, read-write, and trap. The community names are essentially passwords; there's no real difference between a community string and the password you use to access your account on the computer. The three community strings control different kinds of activities. As its name implies, the read-only community string lets you read data values but doesn't let you modify the data. For example, it allows you to read the number of packets that have been transferred through the ports on your router but doesn't let you reset the counters. The read-write community string is allowed to read and modify data values; with the read-write community string, you can read the counters, reset their values, and even reset the interfaces or do other things that change the router's configuration. Finally, the trap community string allows you to receive traps (asynchronous notifications) from the agent.

Most vendors ship their equipment with default community strings , typically public for the read-only community string and private for the read-write community string. It's important to change these defaults before your device goes live on the network. (You may get tired of hearing this because we say it many times, but it's absolutely essential.) When setting up an SNMP agent, you will want to configure its trap destination, which is the address to which it will send any traps it generates. In addition, since SNMP community strings are sent in clear text, you can configure an agent to send an SNMP authentication-failure trap when someone attempts to query your device with an incorrect community string. Among other things, authentication-failure traps can be very useful in determining when an intruder might be trying to gain access to your network.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

So far, we have used the term management information to refer to the operational parameters of SNMP-capable devices. However, we've said very little about what management information actually contains or how it is represented. The first step toward understanding what kind of information a device can provide is to understand how this data is represented within the context of SNMP. The Structure of Management Information Version 1 (SMIv1 , RFC 1155) does exactly that: it defines precisely how managed objects are named and specifies their associated datatypes. The Structure of Management Information Version 2 (SMIv2 , RFC 2578) provides enhancements for SNMPv2. We'll start by discussing SMIv1, and we will discuss SMIv2 in the next section.

The definition of managed objects can be broken down into three attributes:

Name: The name, or object identifier (OID), uniquely defines a managed object. Names commonly appear in two forms: numeric and "human readable." In either case, the names are long and inconvenient. In SNMP applications, a lot of work goes into helping you navigate through the namespace conveniently.
Type and syntax: A managed object's datatype is defined using a subset of Abstract Syntax Notation One (ASN.1 ). ASN.1 is a way of specifying how data is represented and transmitted between managers and agents, within the context of SNMP. The nice thing about ASN.1 is that the notation is machine independent. This means that a PC running Windows 2000 can communicate with a Sun SPARC machine and not have to worry about things such as byte ordering.
Encoding

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SMIv2 extends the SMI object tree by adding the snmpV2 branch to the internet subtree, adding several new datatypes and making a number of other changes. Figure 2-3 shows how the snmpV2 objects fit into the bigger picture; the OID for this new branch is 1.3.6.1.6.3.1.1, or iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects. SMIv2 also defines some new datatypes, which are summarized in Table 2-2.

Figure 2-3: SMIv2 registration tree for SNMPv2

Table 2-2: New datatypes for SMIv2
Datatype	Description
Integer32	Same as an `INTEGER`.
Counter32	Same as a `Counter`.
Gauge32	Same as a `Gauge`.
Unsigned32	Represents decimal values in the range of 0 to 2³² - 1, inclusive.
Counter64	Similar to `Counter32`, but its maximum value is 18,446,744,073,709,551,615. `Counter64` is ideal for situations in which a `Counter32` may wrap back to 0 in a short amount of time.
BITS

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

MIB-II is a very important management group because every device that supports SNMP must also support MIB-II. Therefore, we will use objects from MIB-II in our examples throughout this book. We won't go into detail about every object in the MIB; we'll simply define the subtrees. The section of RFC1213-MIB that defines the base OIDs for the mib-2 subtree looks like this:

mib-2        OBJECT IDENTIFIER ::= { mgmt 1 }
system       OBJECT IDENTIFIER ::= { mib-2 1 }
interfaces   OBJECT IDENTIFIER ::= { mib-2 2 }
at           OBJECT IDENTIFIER ::= { mib-2 3 }
ip           OBJECT IDENTIFIER ::= { mib-2 4 }
icmp         OBJECT IDENTIFIER ::= { mib-2 5 }
tcp          OBJECT IDENTIFIER ::= { mib-2 6 }
udp          OBJECT IDENTIFIER ::= { mib-2 7 }
egp          OBJECT IDENTIFIER ::= { mib-2 8 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp         OBJECT IDENTIFIER ::= { mib-2 11 }

mib-2 is defined as iso.org.dod.internet.mgmt.1, or 1.3.6.1.2.1. From here, we can see that the system group is mib-2 1, or 1.3.6.1.2.1.1, and so on. Figure 2-4 shows the MIB-II subtree of the mgmt branch.

Figure 2-4: MIB-II subtree

Table 2-5 briefly describes each management group defined in MIB-II. We don't go into great detail about each group since you can pull down RFC 1213 and read the MIB yourself.

Table 2-5: Brief description of the MIB-II groups
Subtree name	OID	Description
system

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We've discussed how SNMP organizes information, but we've left out how we actually go about gathering management information. Now we're going to take a look under the hood to see how SNMP does its thing.

The Protocol Data Unit (PDU) is the message format that managers and agents use to send and receive information. Each of the following SNMP operations has a standard PDU format:

get
getnext
getbulk (SNMPv2 and SNMPv3)
set
getresponse
trap
notification (SNMPv2 and SNMPv3)
inform (SNMPv2 and SNMPv3)
report (SNMPv2 and SNMPv3)

In addition to running actual command-line tools, we will also provide packet dumps of the SNMP operations. For those of you who like looking at packet dumps, this will give you an inside look at what the packet structure is for each command. The packet dumps themselves were taken using the command-line version of Ethereal (http://www.ethereal.com). Let's take a look at each operation now. All of the get and set operations were captured with the following command:

$ /usr/sbin/tethereal -i lo -x -V -F libpcap -f "port 161"

Traps and notifications were captured with this command:

$ /usr/sbin/tethereal -i lo -x -V -F libpcap -f "port 162"

The get request is initiated by the NMS, which sends the request to the agent. The agent receives the request and processes it to the best of its ability. Some devices that are under heavy load, such as routers, may not be able to respond to the request and will have to drop it. If the agent is successful in gathering the requested information, it sends a getresponse back to the NMS, where it is processed. This process is illustrated in Figure 2-5.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Managing your hosts is an important part of network management. You would think that the Host Resources MIB would be part of every host-based SNMP agent, but this isn't the case. Some SNMP agents implement this MIB, but many don't. A few agents go further and implement proprietary extensions based upon this MIB. This is mainly due to the fact that this MIB was intended to serve as a basic, watered-down framework for host management , designed mainly to foster wide deployment.

The Host Resources MIB defines the following seven groups:

host            OBJECT IDENTIFIER ::= { mib-2 25 }

hrSystem        OBJECT IDENTIFIER ::= { host 1 }
hrStorage       OBJECT IDENTIFIER ::= { host 2 }
hrDevice        OBJECT IDENTIFIER ::= { host 3 }
hrSWRun         OBJECT IDENTIFIER ::= { host 4 }
hrSWRunPerf     OBJECT IDENTIFIER ::= { host 5 }
hrSWInstalled   OBJECT IDENTIFIER ::= { host 6 }

The host OID is 1.3.6.1.2.1.25 (iso.org.dod.internet.mgmt.mib-2.host). The remaining six groups define various objects that provide information about the system.

The hrSystem (1.3.6.1.2.1.25.1) group defines objects that pertain to the system itself. These objects include uptime, system date, system users, and system processes.

The hrDevice (1.3.6.1.2.1.25.3) and hrStorage (1.3.6.1.2.1.25.2) groups define objects pertaining to filesystems and system storage, such as total system memory, disk utilization, and CPU nonidle percentage. They are particularly helpful since they can be used to manage the disk partitions on your host. You can even use them to check for errors on a given disk device.

The hrSWRun (1.3.6.1.2.1.25.4), hrSWRunPerf (1.3.6.1.2.1.25.5), and hrSWInstalled (1.3.6.1.2.1.25.6 ) groups define objects that represent various aspects of software running or installed on the system. From these groups, you can determine what operating system is running on the host, as well as what programs the host is currently running. The hrSWInstalled group can be used to track which software packages are installed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A thorough treatment of RMON is beyond the scope of this book, but it's worth discussing the groups that make up RMONv1. RMON probes are typically standalone devices that watch traffic on the network segments to which they are attached. Some vendors implement at least some kind of RMON probe in their routers, hubs, or switches. Chapter 8 provides an example of how to configure RMON on a Cisco router.

The RMON MIB defines the following 10 groups:

rmon              OBJECT IDENTIFIER ::= { mib-2 16 }
statistics        OBJECT IDENTIFIER ::= { rmon 1 }
history           OBJECT IDENTIFIER ::= { rmon 2 }
alarm             OBJECT IDENTIFIER ::= { rmon 3 }
hosts             OBJECT IDENTIFIER ::= { rmon 4 }
hostTopN          OBJECT IDENTIFIER ::= { rmon 5 }
matrix            OBJECT IDENTIFIER ::= { rmon 6 }
filter            OBJECT IDENTIFIER ::= { rmon 7 }
capture           OBJECT IDENTIFIER ::= { rmon 8 }
event             OBJECT IDENTIFIER ::= { rmon 9 }

RMONv1 provides packet-level statistics about an entire LAN or WAN. The rmon OID is 1.3.6.1.2.1.16 (iso.org.dod.internet.mgmt.mib-2.rmon). RMONv1 is made up of nine groups:

statistics (1.3.6.1.2.1.16.1): Contains statistics about all the Ethernet interfaces monitored by the probe.
history (1.3.6.1.2.1.16.2): Records periodic statistical samples from the statistics group.
alarm (1.3.6.1.2.1.16.3): Allows a user to configure a polling interval and a threshold for any object the RMON probe records.
hosts (1.3.6.1.2.1.16.4): Records traffic statistics for each host on the network.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You might be wondering why something like this is even a topic for SNMP. Isn't SNMP a standard, you may ask? Well, it is, but that doesn't prevent vendors from doing things in nonstandard, and downright oblique, ways. In some cases, vendors either do not publish their SNMP MIB, or they use SNMP as a means of updating a network device from a GUI. For example, the Netgear WAG302 access point comes with Windows-based management software. This software uses SNMP to gather information from the WAP. The Netgear device supports several standard SNMP MIBs, but it also has support for two additional private MIBs: Netgear's MIB and that of a third-party provider. Netgear doesn't make its private MIB available. Using Ethereal (yes, it is available for Windows, too), you can capture the traffic as you work with a management application, such as the one that comes with the Netgear device, and see what SNMP requests and responses flow over the network.

As we mentioned already, Ethereal does a nice job of telling you things like the SNMP version, error codes, OIDs, and actual data in the PDU. We even get to see the OIDs and their values. For example, the following is an excerpt from the notification trace:

    Object identifier 3: 1.3.6.1.2.1.2.2.1.1 (IF-MIB::ifIndex)
    Value: INTEGER: 2
    Object identifier 4: 1.3.6.1.2.1.2.2.1.7 (IF-MIB::ifAdminStatus)
    Value: INTEGER: up(1)
    Object identifier 5: 1.3.6.1.2.1.2.2.1.8 (IF-MIB::ifOperStatus)
    Value: INTEGER: up(1)

We see that ifIndex is set to INTEGER 2, ifAdminStatus is set to INTEGER 1 (which Ethereal has translated to up for us), and ifOperStatus is set to up as well.

We suggest that you add Ethereal to your arsenal of network tools. It can help you greatly, not only in reverse engineering SNMP, but also in terms of learning about datagram structures and the like.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Security has been the biggest weakness of SNMP since the beginning. Authentication in SNMP versions 1 and 2 amounts to nothing more than a password (community string) sent in clear text between a manager and agent. Any security-conscious network or system administrator knows that clear-text passwords provide no real security at all. It is trivial for someone to intercept the community string, and once he has it, he can use it to retrieve information from devices on your network, modify their configuration, and even shut them down.

The Simple Network Management Protocol Version 3 (SNMPv3) addresses the security problems that have plagued both SNMPv1 and SNMPv2. For all practical purposes, security is the only issue SNMPv3 addresses; there are no other changes to the protocol. There are no new operations; SNMPv3 supports all the operations defined by versions 1 and 2. There are several new textual conventions, but these are really just more precise ways of interpreting the datatypes that were defined in earlier versions.

This chapter provides an introduction to SNMPv3. SNMPv3 agent configurations can be found in Chapter 6. Until recently, SNMPv3 was a draft standard. It is now a full standard. Vendors are notoriously slow to change, but hopefully we will see even more of them begin to support SNMPv3.

Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, its developers have managed to make things look much different by introducing new textual conventions, concepts, and terminology. The changes to the terminology are so radical that it's hard to believe the new terms essentially describe the same software as the old ones, but they do. However, they do differ in how they relate to each other, and they specify much more precisely the pieces that an SNMP implementation needs.

The most important change is that Version 3 abandons the notion of managers and agents. Both managers and agents are now called SNMP entities . Each entity consists of an SNMP engine and one or more SNMP applications, which are discussed in the following sections. These new concepts are important because they define an architecture rather than simply a set of messages; the architecture helps to separate different pieces of the SNMP system in a way that makes a secure implementation possible. Let's look at what these concepts mean, starting with the RFCs that define them (Table 3-1).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, its developers have managed to make things look much different by introducing new textual conventions, concepts, and terminology. The changes to the terminology are so radical that it's hard to believe the new terms essentially describe the same software as the old ones, but they do. However, they do differ in how they relate to each other, and they specify much more precisely the pieces that an SNMP implementation needs.

The most important change is that Version 3 abandons the notion of managers and agents. Both managers and agents are now called SNMP entities . Each entity consists of an SNMP engine and one or more SNMP applications, which are discussed in the following sections. These new concepts are important because they define an architecture rather than simply a set of messages; the architecture helps to separate different pieces of the SNMP system in a way that makes a secure implementation possible. Let's look at what these concepts mean, starting with the RFCs that define them (Table 3-1).

Table 3-1: RFCs for SNMPv3
Number	Name
RFC 3411	Architecture for SNMP Frameworks
RFC 3412	Message Processing and Dispatching
RFC 3413	SNMP Applications
RFC 3414	User-based Security Model (USM)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The User-based Security Model (USM ) and the View Access Control Model (VACM) together detail the security enhancements added with SNMPv3 . Let's start with the USM.

We need to get some terminology out of the way before we can look at the USM in any detail:

snmpEngineID: This is an unambiguous identifier for an SNMP engine as well as the SNMP entity that corresponds to the engine. The syntax for this identifier is OctetString and it cannot be zero length. Most SNMPv3 applications allow for the user to input a value for snmpEngineID. If one is not specified, the value is computed using a combination of enterprise ID and IP or MAC address.
snmpEngineBoots: A count of the number of times an SNMP engine has rebooted.
snmpEngineTime: The number of seconds since the snmpEngineBoots counter was last incremented.
snmpSecurityLevel: There are three security levels. The first is no authentication or privacy (noAuthNoPriv). Note that if this mode is used, a securityName is still required. The second is authentication and no privacy (authNoPriv). The third and final one is authentication and privacy (authPriv). While you can have authentication without privacy, you cannot have privacy without authentication.
Authoritative SNMP engine

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

VACM is used to control access to managed objects in a MIB or MIBs. This is where the Access Control Subsystem comes into play.

The msgFlags, msgSecurityModel, and scopedPDU fields are used by VACM for message access. Each parameter is used to determine access to managed objects. An error is returned to the sender if access is not allowed for the request type. VACM makes use of four tables for different aspects of access control. We will discuss these tables next.

The vacmContextTable is a collection of managed objects that have access constraints which are associated with a context name. The vacmContextTable stores all available contexts. The table is indexed by a contextName, and each row in this table contains:

vacmContextName: A textual name for the context

The vacmSecurityToGroupTable is used to store group information. A group is made up of zero or more securityModel and securityName combinations. This combination defines what managed objects can be accessed. The table itself is indexed by a securityModel and securityName. The table contains rows made up of the following columns:

vacmSecurityModel: The security model in use—e.g., USM.
vacmSecurityName: In the case of the USM, securityName and userName are identical.
vacmGroupName: A textual name for the group to which this table entry belongs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Let's briefly outline the common configuration options you should expect when you have to configure an SNMPv3 device or network management platform:

Username: This is the textual description of the person responsible for the SNMP entity that is to be managed. Sometimes referred to as security name.
Security level: Some applications require you to explicitly set the security level and others determine it based on the combination of authentication and privacy protocol in use. The specified values are noAuthNoPriv, which is no authentication and no privacy, authNoPriv, which is authentication and no privacy, and authPriv, which is authentication and privacy. Note that you cannot have privacy without authentication, but you can have authentication without privacy.
Authentication protocol: The protocol used for authentication—that is, to prove that you are who you say you are. Currently, MD5 and SHA1 are specified in the RFCs.
Authentication passphrase: The passphrase used in conjunction with the authentication protocol. It must be at least eight characters long. You may also see it referred to as a password.
Privacy protocol: The protocol used for privacy, that is, to encrypt the data portion of the SNMP packet. Currently, DES is specified in the RFCs.
Privacy passphrase: The passphrase used in conjunction with the privacy protocol. It must be at least eight characters long. You may also see it referred to as a password.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that you understand the basic concepts behind how network management stations (NMSs) and agents communicate, it's time to introduce the concept of a network management architecture . Before rushing out to deploy SNMP management, you owe it to yourself to put some effort into developing a coherent plan. If you simply drop NMS software on a few of your favorite desktop machines, you're likely to end up with something that doesn't work very well. By NMS architecture, we mean a plan that helps you use NMSs effectively to manage your network. A key component of network management is selecting the proper hardware (i.e., an appropriate platform on which to run your NMS) and making sure that your management stations are located in such a way that they can observe the devices on your network effectively.

Managing a reasonably large network requires an NMS with substantial computing power. In today's complex networked environments, networks can range in size from a few nodes to thousands of nodes. The process of polling and receiving traps from hundreds or thousands of managed entities can be taxing on the best of hardware. Your NMS vendor will be able to help you determine what kind of hardware is appropriate for managing your network. Most vendors have formulas for determining how much RAM you will need to achieve the level of performance you want, given the requirements of your network. It usually boils down to the number of devices you want to poll, the amount of information you will request from each device, and the interval at which you want to poll them. The software you want to run is also a consideration. NMS products such as OpenView are large, heavyweight applications; if you want to run your own scripts with Perl, you can get away with a much smaller management platform.

Is it possible to say something more helpful than "ask your vendor"? Yes. First, although we've become accustomed to thinking of NMS software as requiring a midrange workstation or high-end PC, desktop hardware has advanced so much in the past year or two that running this software is within the range of any modern PC. Specifically, surveying the recommendations of a number of vendors, we have found that they suggest a PC with at least a 2 or 3 GHz CPU, 512 MB to 1 GB of memory, and 1-2 GB of disk space. Requirements for Sun SPARC and HP workstations are similar.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Managing a reasonably large network requires an NMS with substantial computing power. In today's complex networked environments, networks can range in size from a few nodes to thousands of nodes. The process of polling and receiving traps from hundreds or thousands of managed entities can be taxing on the best of hardware. Your NMS vendor will be able to help you determine what kind of hardware is appropriate for managing your network. Most vendors have formulas for determining how much RAM you will need to achieve the level of performance you want, given the requirements of your network. It usually boils down to the number of devices you want to poll, the amount of information you will request from each device, and the interval at which you want to poll them. The software you want to run is also a consideration. NMS products such as OpenView are large, heavyweight applications; if you want to run your own scripts with Perl, you can get away with a much smaller management platform.

Is it possible to say something more helpful than "ask your vendor"? Yes. First, although we've become accustomed to thinking of NMS software as requiring a midrange workstation or high-end PC, desktop hardware has advanced so much in the past year or two that running this software is within the range of any modern PC. Specifically, surveying the recommendations of a number of vendors, we have found that they suggest a PC with at least a 2 or 3 GHz CPU, 512 MB to 1 GB of memory, and 1-2 GB of disk space. Requirements for Sun SPARC and HP workstations are similar.

Let's look at each of these requirements:

2 or 3 GHz CPU: This is well within the range of any modern desktop system, but you probably can't bring your older equipment out of retirement to use as a management station.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before going out and buying all your equipment, it's worth spending some time coming up with an architecture for your network that will make it more manageable. The simplest architecture has a single management station that is responsible for the entire network, as shown in Figure 4-1.

The network depicted in Figure 4-1 has three sites: New York, Atlanta, and San Jose. The NMS in New York is responsible for managing not only the portion of the network in New York, but also those in Atlanta and San Jose. Traps sent from any devi

Table of Contents