Essential SNMP | O'Reilly Media

Content preview·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 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.

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

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 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.

Before going any further, let's look at a before-and-after scenario that shows how SNMP can make a difference in an organization.

Let's say that you have a network of 100 machines running various operating systems. Several machines are file servers, a few others are print servers, another is running software that verifies credit card transactions (presumably from a web-based ordering system), and the rest are personal workstations. In addition, there are various switches and routers that help keep the actual network going. A T1 circuit connects the company to the global Internet, and there is a private connection to the credit card verification 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 reprint rights for this chapter

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 proposed standards, then move to draft status. When a final draft is eventually approved, the RFC is given standard status -- although there are fewer completely approved standards than you might think. Two other standards-track designations, historical and experimental, define (respectively) a document that has been replaced by a newer RFC and a document that is not yet ready to become a standard. The following list includes all the current SNMP versions and the IETF status of each (see Appendix D for a full list of the SNMP RFCs):

SNMP Version 1 (SNMPv1) is the current standard version of the SNMP protocol. It's defined in RFC 1157 and is a full IETF standard. SNMPv1's security is based on communities, which are nothing more than passwords: plain-text strings that allow any SNMP-based application that knows the strings to gain access to a device's management information. There are typically three communities in SNMPv1: read-only, read-write, and trap.
SNMP Version 2 (SNMPv2) is often referred to as community string-based SNMPv2. This version of SNMP is technically called SNMPv2c, but we will refer to it throughout this book simply as SNMPv2. It's defined in RFC 1905, RFC 1906, and RFC 1907, and is an experimental IETF. Even though it's experimental, some vendors have started supporting it in practice.
SNMP Version 3 (SNMPv3) will be the next version of the protocol to reach full IETF status. It's currently a proposed standard, defined in RFC 1905, RFC 1906, RFC 1907, RFC 2571, RFC 2572, RFC 2573, RFC 2574, and RFC 2575. It adds support for strong authentication and private communication between managed entities. Appendix F provides an introduction to SNMPv3 and goes through the SNMPv3 agent configuration for Net-SNMP and Cisco. The information in this appendix provides any system or network administrator with the practical knowledge needed to begin using SNMPv3 as it gains acceptance in the network-management world.

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 reprint rights for this chapter

In the previous sections we've vaguely referred to SNMP-capable devices and network-management stations. Now it's time to describe what these two things really are. In the world of SNMP there are two kind of entities: managers and agents. A manager is a server running some kind of software system that can handle management tasks for a network. Managers are often referred to as Network Management Stations (NMSs). An NMS is responsible for polling and receiving traps from agents in the network. A poll, in the context of network management, is the act of querying an agent (router, switch, Unix server, etc.) for some piece of information. This information can later be used to determine if some sort of catastrophic event has occurred. A trap is a way for the agent to tell the NMS that something has happened. Traps are sent asynchronously, not in response to queries from the NMS. The NMS is further responsible for performing an action based upon the information it receives from the agent. For example, when your T1 circuit to the Internet goes down, your router can send a trap to your NMS. In turn, the NMS can take some action, perhaps paging you to let you know that something has happened.

The second entity, the agent, is a piece of software that runs on the network devices you are managing. It can be a separate program (a daemon, in Unix language), or it can be incorporated into the operating system (for example, Cisco's IOS on a router, or the low-level operating system that controls a UPS). Today, most IP devices come with some kind of SNMP agent built in. The fact that vendors are willing to implement agents in many of their products makes the system administrator's or network manager's job easier. The agent provides management information to the NMS by keeping track of various operational aspects of the device. For example, the agent on a router is able to keep track of the state of each of its interfaces: which ones are up, which ones are down, etc. The NMS can query the status of each interface on a router, and take appropriate action if any of them are down. When the agent notices that something bad has happened, it can send a trap to the NMS. This trap originates from the agent and is sent to the NMS, where it is handled appropriately. Some devices will send a corresponding "all clear" trap when there is a transition from a bad state to a good state. This can be useful in determining when a problem situation has been resolved. Figure 1-1 shows the relationship between the NMS and an agent.

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 reprint rights for this chapter

The Structure of Management Information (SMI) provides a way to define managed objects and their behavior. An agent has in its possession a list of the objects that it tracks. One such object is the operational status of a router interface (for example, up, down, or testing). This list collectively defines the information the NMS can use to determine the overall health of the device on which the agent resides.

The Management Information Base (MIB) can be thought of as a database of managed objects that the agent tracks. Any sort of status or statistical information that can be accessed by the NMS is defined in a MIB. The SMI provides a way to define managed objects, while the MIB is the definition (using the SMI syntax) of the objects themselves. Like a dictionary, which shows how to spell a word and then gives its meaning or definition, a MIB defines a textual name for a managed object and explains its meaning. Chapter 2 goes into more technical detail about MIBs and the SMI.

An agent may implement many MIBs, but all agents implement a particular MIB called MIB-II (RFC 1213). This standard defines variables for things such as interface statistics (interface speeds, MTU, octets sent, octets received, etc.) as well as various other things pertaining to the system itself (system location, system contact, etc.). The main goal of MIB-II is to provide general TCP/IP management information. It doesn't cover every possible item a vendor may want to manage within its particular device.

What other kinds of information might be useful to collect? First, there are many draft and proposed standards developed to help manage things such as frame relay, ATM, FDDI, and services (mail, DNS, etc.). A sampling of these MIBs and their RFC numbers includes:

ATM MIB (RFC 2515)
Frame Relay DTE Interface Type MIB (RFC 2115)
BGP Version 4 MIB (RFC 1657)

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 reprint rights for this chapter

Managing host resources (disk space, memory usage, etc.) is an important part of network management. The distinction between traditional system administration and network management has been disappearing over the last decade, and is now all but gone. As Sun Microsystems puts it, "The network is the computer." If your web server or mail server is down, it doesn't matter whether your routers are running correctly -- you're still going to get calls. The Host Resources MIB (RFC 2790) defines a set of objects to help manage critical aspects of Unix and Windows systems.

Some of the objects supported by the Host Resources MIB include disk capacity, number of system users, number of running processes, and software currently installed. In today's e-commerce world, more and more people are relying on service-oriented web sites. Making sure your backend servers are functioning properly is as important as monitoring your routers and other communications devices.

Unfortunately, some agent implementations for these platforms do not implement this MIB, since it's not required.

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 reprint rights for this chapter

Remote Monitoring Version 1 (RMONv1, or RMON) is defined in RFC 2819; an enhanced version of the standard, called RMON Version 2 (RMONv2), is defined in RFC 2021. RMONv1 provides the NMS with packet-level statistics about an entire LAN or WAN. RMONv2 builds on RMONv1 by providing network- and application-level statistics. These statistics can be gathered in several ways. One way is to place an RMON probe on every network segment you want to monitor. Some Cisco routers have limited RMON capabilities built in, so you can use their functionality to perform minor RMON duties. Likewise, some 3Com switches implement the full RMON specification and can be used as full-blown RMON probes.

The RMON MIB was designed to allow an actual RMON probe to run in an offline mode that allows the probe to gather statistics about the network it's watching without requiring an NMS to query it constantly. At some later time, the NMS can query the probe for the statistics it has been gathering. Another feature that most probes implement is the ability to set thresholds for various error conditions and, when a threshold is crossed, alert the NMS with an SNMP trap. You can find a little more technical detail about RMON in the next chapter.

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 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. The most notable web site is the Network Management Server at the University at Buffalo (http://netman.cit.buffalo.edu). It contains useful links to other sites that provide similar information, as well as a network-management product list (http://netman.cit.buffalo.edu/Products.html) that includes both software and hardware vendors; it even has product reviews. This site is a great starting point in the search for network-management information and can be an extremely useful tool for determining what kinds of hardware and software are currently out there. Two more great web sites are the SimpleWeb (http://www.snmp.cs.utwente.nl) and SNMP Link (http://www.SNMPLink.org). The Simple Times, an online publication devoted to SNMP and network management, is also useful. You can find the current edition, and all the previous ones, at http://www.simple-times.org.

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.

If you would like to know if a particular vendor has SNMP-compatible equipment, the Internet Assigned Numbers Authority (IANA) has compiled a list of the proprietary MIB files various vendors supply. The list can be found at ftp://ftp.iana.org/mib/. There is also 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/.

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 reprint rights for this chapter

In this chapter, we start to look at SNMP in detail. By the time you finish this chapter, you should understand how SNMP sends and receives information, what exactly 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.

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 will flood 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 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 will flood 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 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 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 and private for the read-write community. 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.

Because community strings are essentially passwords, you should use the same rules for selecting them as you use for Unix or NT user passwords: no dictionary words, spouse names, etc. An alphanumeric string with mixed upper- and lowercase letters is generally a good idea. As mentioned earlier, the problem with SNMP's authentication is that community strings are sent in plain text, which makes it easy for people to intercept them and use them against you. SNMPv3 addresses this by allowing, among other things, secure authentication and communication between SNMP devices.

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 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 itself 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 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 NT can communicate with a Sun SPARC machine and not have to worry about things such as byte ordering.

Encoding: A single instance of a managed object is encoded into a string of octets using the Basic Encoding Rules(BER). BER defines how the objects are encoded and decoded so they can be transmitted over a transport medium such as Ethernet.

Managed objects are organized into a tree-like hierarchy. This structure is the basis for SNMP's naming scheme. An object ID is made up of a series of integers based on the nodes in the tree, separated by dots (.). Although there's a human-readable form that's more friendly than a string of numbers, this form is nothing more than a series of names separated by dots, each of which represents a node of the tree. So you can use the numbers themselves, or you can use a sequence of names that represent the numbers. Figure 2-2 shows the top few levels of this tree. (We have intentionally left out some branches of the tree that don't concern us here.)

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 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	An enumeration of nonnegative named bits.

The definition of an object in SMIv2 has changed slightly from SMIv1. There are some new optional fields, giving you more control over how an object is accessed, allowing you to augment a table by adding more columns, and letting you give better descriptions. Here's the syntax of an object definition for SMIv2. The changed parts are in bold:

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 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 of the management groups 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	1.3.6.1.2.1.1	Defines a list of objects that pertain to system operation, such as the system uptime, system contact, and system name.

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 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. There is a standard PDU format for each of the following SNMP operations:

get
get-next
get-bulk (SNMPv2 and SNMPv3)
set
get-response
trap
notification (SNMPv2 and SNMPv3)
inform (SNMPv2 and SNMPv3)
report (SNMPv2 and SNMPv3)

Let's take a look at each of these operations.

The get request is initiated by the NMS, which sends the request to the agent. The agent receives the request and processes it to 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 get-response back to the NMS, where it is processed. This process is illustrated in Figure 2-5.

Figure 2-5: get request sequence

How did the agent know what the NMS was looking for? One of the items in the get request is a variable binding. A variable binding, or varbind, is a list of MIB objects that allows a request's recipient to see what the originator wants to know. Variable bindings can be thought of as OID=value pairs that make it easy for the originator (the NMS, in this case) to pick out the information it needs when the recipient fills the request and sends back a response. Let's look at this operation in action:

$ snmpget cisco.ora.com public .1.3.6.1.2.1.1.6.0
system.sysLocation.0 = ""

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 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

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 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 stand-alone 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 9 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

hostTopN (1.3.6.1.2.1.16.5): Contains host statistics used to generate reports on hosts that top a list ordered by a parameter in the host table

matrix (1.3.6.1.2.1.16.6 ): Stores error and utilization information for sets of two addresses

filter (1.3.6.1.2.1.16.7): Matches packets based on a filter equation; when a packet matches the filter, it may be captured or an event may be generated

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 reprint rights for this chapter

Now that you understand the basic concepts behind how 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 300 MHz CPU, 128 MB of memory, and 500 MB 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 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 300 MHz CPU, 128 MB of memory, and 500 MB of disk space. Requirements for Sun SPARC and HP workstations are similar.

Let's look at each of these requirements:

300 MHz 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.

128 MB of memory: You'll probably have to add memory to any off-the-shelf PC; Sun and HP workstations come with more generous memory configurations. Frankly, vendors tend to underestimate memory requirements anyway, so it won't hurt to upgrade to 256 MB. Fortunately, RAM is cheap these days. (Memory prices fluctuate from day to day, but we recently found 256 MB DIMMs for under $100.)

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 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 3-1.

Figure 3-1: Single NMS architecture

The network depicted in Figure 3-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 device in Atlanta or San Jose must travel over the Internet to get to the NMS in New York. The same thing goes for polling devices in San Jose and Atlanta: the NMS in New York must send its requests over the Internet to reach these remote sites. For small networks, an architecture like this can work well. However, when the network grows to the point that a single NMS can no longer manage everything, this architecture becomes a real problem. The NMS in New York can get behind in its polling of the remote sites, mainly because it has so much to manage. The result is that when problems arise at a remote site, they may not get noticed for some time. In the worst case, they might not get noticed at all.

It's also worth thinking about staffing. With a single NMS, your primary operations staff would be in New York, watching the health of the network. But problems frequently require somebody onsite to intervene. This requires someone in Atlanta and San Jose, plus the coordination that entails. You may not need a full-time network administrator, but you will need someone who knows what to do when a router fails.

When your network grows to a point where one NMS can no longer manage everything, it's time to move to a distributed NMS architecture. The idea behind this architecture is simple: use two or more management stations and locate them as close as possible to the nodes they are managing. In the case of our three-site network, we would have an NMS at each site. Figure 3-2 shows the addition of two NMSs to 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 reprint rights for this chapter

Web-based network management entails the use of the HyperText Transport Protocol (HTTP) and the Common Gateway Interface (CGI) to manage networked entities. It works by embedding a web server in an SNMP-compatible device, along with a CGI engine to convert SNMP-like requests (from a web-based NMS) to actual SNMP operations, and vice versa. Web servers can be embedded into such devices at very low monetary and operating cost.

Figure 3-4 is a simplified diagram of the interaction between a web-based NMS and a managed device. The CGI application bridges the gap between the management application and the SNMP engine. In some cases, the management application can be a collection of Java applets that are downloaded to the web browser and executed on the web-based manager. Current versions of OpenView ship with a web-based GUI.

Figure 3-4: Web-based network management

Web-based network management could eliminate, or at least reduce, the need for traditional NMS software. NMS software can be expensive to purchase, set up, and maintain. Most of today's major NMS vendors support only a few popular versions of Unix, and have only recently begun to support Windows 9x/NT/2000, thus limiting your operating-system choices. With a web-based NMS, however, these two concerns are moot. For the most part web-browser technology is free, and Netscape Communications (now AOL Time Warner) supports many flavors of Unix, as well as the Wintel and Apple platforms.

Web-based network management should not be viewed as a panacea, though. It is a good idea, but it will take some time for vendors to embrace this technology and move toward web-integration of their existing products. There is also the issue of standardization, or the lack of it. The Web-Based Enterprise Management (WBEM) consortium addresses this by defining a standard for web-based management. Industry leaders such as Cisco and BMC Software are among the original founders of WBEM. You can learn more about this initiative at the Distributed Management Task Force's web page,

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 reprint rights for this chapter

Determining if you have devices that are manageable by SNMP is a good place to start down the path to network-management Zen. Before we get into how to determine if what you already have is manageable, we will briefly discuss what makes a device SNMP-compatible.

Vendors do not have to implement all the MIBs SNMP provides, but SNMP-manageable devices must support at least MIB-II. It also behooves the vendors to implement some of the more useful MIBs, as well as their own private MIBs, since the ability to manage a product effectively using SNMP is an increasingly important selling point.

Many vendors claim that their products are SNMP-compatible or compliant. For the most part this is true. What they actually mean is that their product supports a set of SNMP operations, as well as MIB-II. For SNMPv1 compatibility, the supported operations include:

get
get-next
set
get-response
trap

Additionally, if the product is SNMPv2 and SNMPv3 compatible, it must support the following operations:

get-bulk
inform
notification
report

Vendors can choose to support SNMPv1, SNMPv2, SNMPv2, or all three. An SNMP agent that supports two versions of SNMP is called "bilingual." In recent years, this was restricted to devices supporting SNMPv1 and SNMPv2. Now a device can support all three versions, which technically makes it trilingual. It is possible for an agent to speak all versions of SNMP because SMIv2 is a superset of SMIv1, and SMIv2 is used, for the most part, with SNMPv3.

Supporting these operations, however, is only one piece to the puzzle of providing a manageable product. The other piece is providing a private MIB that is comprehensive enough to give network managers the information they need to manage their networks intelligently. In today's complex network environments, it does not pay to purchase equipment that has a minimal or poorly implemented private MIB. For instance, it is important to measure ambient temperature inside devices such as routers, hubs, and switches. Cisco and others provide this information via their private MIBs; other vendors do not. If you're in the process of purchasing a high-end router, you might want to look into the vendors' private MIBs to see which vendors provide more relevant information.

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 reprint rights for this chapter

Many vendors claim that their products are SNMP-compatible or compliant. For the most part this is true. What they actually mean is that their product supports a set of SNMP operations, as well as MIB-II. For SNMPv1 compatibility, the supported operations include:

get
get-next
set
get-response
trap

Additionally, if the product is SNMPv2 and SNMPv3 compatible, it must support the following operations:

get-bulk
inform
notification
report

Vendors can choose to support SNMPv1, SNMPv2, SNMPv2, or all three. An SNMP agent that supports two versions of SNMP is called "bilingual." In recent years, this was restricted to devices supporting SNMPv1 and SNMPv2. Now a device can support all three versions, which technically makes it trilingual. It is possible for an agent to speak all versions of SNMP because SMIv2 is a superset of SMIv1, and SMIv2 is used, for the most part, with SNMPv3.

Supporting these operations, however, is only one piece to the puzzle of providing a manageable product. The other piece is providing a private MIB that is comprehensive enough to give network managers the information they need to manage their networks intelligently. In today's complex network environments, it does not pay to purchase equipment that has a minimal or poorly implemented private MIB. For instance, it is important to measure ambient temperature inside devices such as routers, hubs, and switches. Cisco and others provide this information via their private MIBs; other vendors do not. If you're in the process of purchasing a high-end router, you might want to look into the vendors' private MIBs to see which vendors provide more relevant information.

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 reprint rights for this chapter

Your product documentation should be helpful in determining hardware or software compatibility with SNMP. You can also consult your sales representative, or customer support, if applicable. Another way to tell if a product is SNMP-compatible is to perform an snmpget query against the device in question. Issuing a diagnostic get against any device is easy. The most common way to accomplish this is to find a Unix host that has the snmpget binary command installed. There are several varieties of this command, so consult your manpage or system administrator for help. The easiest variable to query for is sysDescr, which provides a description of the system being queried. Here's what happens when you use the Net-SNMP snmpget command to look at sysDescr on a typical Linux host:

$ snmpget linuxserver.ora.com public system.sysDescr.0
system.sysDescr.0 = "Linux version 2.0.34 (root@porky.redhat.com) 
(gcc version 2.7.2.3) #1 Fri May 8 16:05:57 EDT 1998"

The response from linuxserver.ora.com is typical of most managed devices. Note, however, that there's nothing sacred about the actual description; the text you retrieve will vary from vendor to vendor. Issuing an snmpget against a Cisco 2503 router should return something like this:

$ snmpget orarouter.ora.com public system.sysDescr.0
system.sysDescr.0 = "Cisco Internetwork Operating System Software 
..IOS (tm) 2500 Software (C2500-I-L), Version 11.2(5), RELEASE 
SOFTWARE (fc1)..Copyright (c) 1986-1997 by cisco Systems, Inc...
Compiled Mon 31-Mar-97 19:53 by ckralik"

This router's system description tells us that it is running Version 11.2(5) of the Cisco IOS. This sort of information is generally useless, but it does tell us that the device is running an SNMP agent. Here's what happens when something goes wrong:

$ snmpget linuxserver.ora.com public system.sysDescr.0
Timeout: No Response from linuxserver.ora.com.

This message means that the Net-SNMP snmpget command did not receive a response from linuxserver.ora.com. A number of things could be wrong, one of which is that there is no SNMP agent running on the target host. But it's also possible that

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 reprint rights for this chapter

Now that you know whether or not you have SNMP devices on your network, it might be time to upgrade! You may find that some of the devices you would like to manage don't support SNMP. There are two ways to upgrade: you can retire your existing equipment and buy newer, more manageable hardware, or you can upgrade your equipment's firmware (if provided by the vendor) to a version that supports SNMP. Some vendors, however, will offer to buy back older equipment, or even give a discount for turning in a competitor's equipment.

Of course, updating your equipment may not be necessary. If you have software applications that are used to manage non-SNMP equipment and they work, there is no need to upgrade. If you're reasonably handy with scripts and want to learn about SNMP in some depth, you may find that it's possible to write scripts that allow you to use SNMP to monitor applications that doesn't support SNMP using wrapper/scripts. For an example of this, see xref linkend="enettdg-CHP-12-SECT-4"/> in Chapter 12.

Whatever approach you take, realize that SNMP exists to provide a consistent way to manage networked equipment. If you're currently managing your network using a number of legacy management tools, each supporting a few devices from a particular vendor, SNMP provides a way out. You may be comfortable with your old tools -- but it will become increasingly convenient to use SNMP to provide a uniform network-management approach.

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 reprint rights for this chapter

You may have been purchasing SNMP-compatible devices for years without knowing it. As SNMP has become more popular, it has been incorporated into more and more devices. SNMP compatibility has become a true selling point for most vendors.

It goes without saying that most network devices support SNMP, including routers, bridges, hubs, servers, and desktop PCs. However, many other kinds of equipment are also manageable via SNMP, including uninterruptible power supplies (UPSs), air-conditioning units, and other important pieces of your infrastructure. After you identify which routers and hubs are SNMP-compatible, keep your eyes open for other devices that may need to be managed. While SNMP is very good at managing your network, hosts, hubs, and routers, it's not limited to only your networking environment.

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 reprint rights for this chapter

The Internet Engineering Task Force (IETF) is in the process of defining a standards-track technology for SNMP agent extensibility (AgentX). As we defined it earlie

Table of Contents