2.1 Overview of SNMP

SNMP stands for Simple Network Management Protocol, and it is exactly what it sounds like: a relatively simple protocol used to manage devices on a network. The managed device is commonly a workstation, a switch, or a router but can be anything capable of speaking IP. For example, many printers and uninterruptible power supplies (UPSs) can be managed with SNMP. What exactly does it mean to be able to "manage" a device? It means an operator, or an SNMP management agent acting on behalf of an operator, can query the device for information and may also be able to instruct the device to make a change in configuration. In managing a router, an operator might use SNMP to query the router for the number of packets transmitted on an interface or instruct the router to make a change to its routing table.

The strength of SNMP lies in its simplicity and its standardization. Because the protocol is simple, it can be implemented in even the most basic devices. The fact that it is an Internet standard makes it an attractive tool for a site that has many devices from many different vendors . Each device may operate differently under the hood, but all devices must present the same management interface via SNMP. Then an operator can manage every device on the network in nearly the same way. The result of SNMP's ubiquity is that it is now the underlying technology for other management tools, including Neo and MRTG, which are discussed in later chapters.

There are currently three versions of SNMP: SNMPv1, SNMPv2, and SNMPv3. SNMPv2 is not drastically different from SNMPv1, and SNMPv3, which adds security to the protocol, is not as widely deployed as the first two. This chapter focuses primarily on SNMPv1.

2.1.1 SNMP

When we talk about using SNMP for network management, we're really talking about a small collection of standards. SNMP itself is the protocol used to transmit management packets over the network. Other standards define how pieces of management information are named and organized. SNMP is built on top of the User Datagram Protocol (UDP). Because UDP is an unreliable protocol by design, there is nothing to ensure that SNMP packets will not be lost in transmission. Accordingly , most management agent software implements a timeout and retransmission to ensure that SNMP messages are received.

Three pieces of information are included in each SNMP packet before the actual management information. First is the version number, which for SNMPv1 is the value zero. Next is the SNMP community name . The community is a text string that serves as a rudimentary kind of authentication. The device being managed is configured ahead of time to allow certain communities access to certain management capabilities. For example, you may give a community called my-secret access only to retrieve management information from a device while you may give the community really-secret access to both change and retrieve it. The operator or management agent supplies the appropriate community name in the SNMP request, and upon receipt of the request, the device decides whether the given community has the necessary privileges.

It is important to note that in SNMPv1 and SNMPv2, the community name is not encrypted in the packet in any way. It is sent over the network as a cleartext password. This means that if these packets are in some way intercepted, an eavesdropper will easily be able to pick out the community name. If the managed device has no access restrictions in place other than the community name, the eavesdropper will now be able to use the community to perform management requests against the device. SNMPv3, in contrast, does have a real authentication mechanism so that an eavesdropper will not be able to gain privileged access. Unfortunately, SNMPv3 is not available on many manageable devices. This means the only options may be to:

  • Disable some or all SNMP access

  • Design your network in such a way that management traffic does not travel on networks where a malicious user may eavesdrop

  • Use a firewall or other filter to block SNMP traffic from untrusted sources

  • Enforce no special access restrictions and hope for the best

Network operators should consider what the security implications would be of unauthorized read- and write-level access to network devices and make management access decisions accordingly. Incidentally, should you wish to make your SNMP management open to everyone, the accepted default value for the community name is public . [1]

[1] At MIT we set the read-only community to public so that anyone may query devices for information. The read-write community is, of course, not open to the public.

The third piece of information sent in the SNMP header indicates the type of request being sent and is called the Protocol Data Unit (PDU) type . PDU is just a fancy word for a packet. There are five valid choices for the PDU type, listed in Figure 2.1. A get-request asks the device to return a piece of information while a set-request asks the device to change a setting. The get-response is the device's response to one of those requests. The other two PDU types, get-next-request and trap , are discussed later in this chapter.

Figure 2.1. PDU Types in SNMPv1.

PDU Type

Name

Function

get-request

Retrieve a variable's value

1

get-next-request

Retrieve the next variable and its value

2

get-response

Response from the managed device

3

set-request

Set a variable's value

4

trap

Spontaneous information from the device

2.1.2 Variables and the MIB

While the SNMP standard defines a framework for talking to a device about management, we need a common way to talk about the information we wish to retrieve or change. Each piece of information available via SNMP is called an SNMP variable . There is a variable that indicates the operational status of an interface, for example, called ifOperStatus . Another variable, called sysUpTime , represents the amount of time the given device has been up and running.

Every SNMP variable is specified in the Management Information Base, more commonly called the MIB . The MIB is a separate standard from SNMP. The job of the MIB is to:

  • Assign every variable a textual name

  • Define a data type for the variable

  • Describe the function of the variable and how the data type is used to achieve that function

  • Define the access possibilities for the variable (e.g., read-only versus read-write)

Practically speaking, the MIB is a text file that lists SNMP variables and all the necessary information associated with them. The file is written in Abstract Syntax Notation One (ASN.1), a standard format for describing data, so that it is readable both by humans and by programs that act as SNMP agents . The data types themselves are further standardized by the Structure of Management Information (SMI) standard, which defines data types such as "TimeTicks" or "IpAddress."

The first MIB, the Internet Standard MIB, was published by the Internet Engineering Task Force (IETF) in 1998 as RFC 1066. [2] RFC 1158 and, later, RFC 1213 describe a new Internet MIB called MIB-II, which effectively replaces the original MIB. Any device speaking SNMP today is required to implement MIB-II.

[2] This document was also revised very slightly and published in 1990 as RFC 1156, but these modifications did not reflect any technical changes in the system.

There are now so many SNMP variables in use that it is not feasible to have one file that describes them all. Additionally, it is desirable for individual enterprises , such as private companies, to have control over their own set of variables. These variables might control products they produce, for example. So instead of one large MIB file, there are many separate component files, some published by the IETF but also many published by vendors.

Note that the term MIB is sometimes used to refer to the Internet standard MIB, which now effectively means MIB-II. But other times, it refers to some particular portion of the MIB that is published separately. So while a purist might say there is only one MIB, it is common to hear someone talk about the "Bridge MIB" or an "Asante MIB." It is usually clear from context what is meant .

In the following sections we look at the MIB in closer detail, but still only as an introduction to the topic. For an in-depth discussion of MIBs, read Understanding SNMP MIBS (Prentice Hall PTR, 1996) by David Perkins and Evan McGinnis.

2.1.3 Object Identifiers and Variable Hierarchy

SNMP variable names must be globally unique. To help achieve this goal, they are arranged in a hierarchical fashion. The sysUpTime variable mentioned earlier is really named in full .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime . The sysUpTime variable belongs to a set of variables under the system group that all relate to management information about the state of the device as a whole. The ifOperStatus variable, which indicates the operational status of an interface, is found under the interfaces tree, which contains variables relating to interface-specific information.

The root of the variable hierarchy has no name, but it has three children, depicted in Figure 2.2. One is for use by the International Organization for Standardization (ISO), one for the Comit Consultatif International T l phonique et T l graphique (CCITT) (now the International Telecommunications Union [ITU]), and the third is for joint ISO and CCITT use. The scope of this naming scheme is actually much larger than that used by SNMP. All SNMP variables in use on the Internet fall under the .iso.org.dod.internet branch of the tree.

Figure 2.2. Object Identifier Hierarchy.

graphics/02fig02.gif

In addition to having a textual name, each branch of the tree has an integer associated with it. This number is used in communicating variable names over the wire in SNMP. The textual names are for human readability only. So .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime , when encoded in an SNMP packet, is sent as .1.3.6.1.2.1.1.3 . This string of integers is called the variable's object identifier , often abbreviated to object ID or OID .

The mib-2 branch of the variable hierarchy is where the Internet standard MIB begins. The private.enterprises portion of the tree is where MIBs assigned to private organizations begins.

2.1.4 Variable Instances for Simple Variables

When making an SNMP request for a simple variable, such as sysUpTime , you must append a final .0 to the variable name, for reasons that will become clear when SNMP tables are discussed in Section 2.1.5. For example, sysUpTime must actually be requested as sysUpTime.0 or at the protocol level, .1.3.6.1.2.1.1.3.0 . The SNMP tools will require you to supply the final .0 when you make requests.

2.1.5 Introduction to Tables

Some kinds of management information, such as the name of the system contact, can be easily stored in a single variable. Other kinds of information are better described in a table of values. For example, if a device has 24 ports, it would be convenient to represent traffic data as a table with 24 rows, one for each port.

The MIB has a facility for defining a table. Instead of going into great detail on how tables are designed, it's easier to look at a real example:

 
 interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.3 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.4 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.5 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.6 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.7 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.8 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.9 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.10 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.11 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.12 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.13 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.14 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.15 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.16 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.17 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.18 = down(2) 

This is a portion of the interfaces group, which is a direct child of mib-2 (see Figure 2.3. The interfaces group is made up of one simple variable ( ifNumber , the number of interfaces on the system) and one table called ifTable . The preceding output is only a small portion of the ifTable , in particular the portion showing the operational status of an interface. Instead of a .0 on the end of each variable name, a number is appended that acts as an index into a row of the table. For the interface table, this index typically corresponds to the interface port number. In the example, we can determine that port one is operational while port ten is not. On Ethernet switches, this often means that port one has link while port ten does not.

Figure 2.3. Children of mib-2 Defined in RFC 1213.

graphics/02fig03.gif

The interface table has many columns other than the ifOperStatus column that contain additional data about the interface. The ifSpeed column, for example, indicates the bandwidth of the interface, and the ifInOctets column contains the number of bytes of data received by the interface.

2.1.6 Lexicographic Ordering and Get-Next-Request

Because each SNMP variable name is an ordered sequence of integers, it is possible to list variables in a lexicographic order. That is, every variable comes numerically before or after another variable, and so a complete ordered listing of all the variables a device uses can be made. This ordering gives purpose to the get-next-request PDU type. Using the get-request PDU type, we supply a variable name and the managed device returns the variable's value, along with the name of the variable we requested. When we make a request with the get-next-request PDU type, we supply a variable name and the managed device returns the value of the next SNMP variable it knows about, along with the name of that variable.

This is a convenient way to walk through a table. We continue asking for the next variable in the table until we either find a variable that is no longer of interest or run out of variables. If we start at the root, get-next-request will allow us to step through the entire tree of variables that a device supports. An example is given in Section 2.4.3, when the snmpwalk tool is discussed.

2.1.7 Traps

The trap PDU type is a special kind of SNMP message. Instead of generating an SNMP message in response to a query, a device can spontaneously send a trap to a listening SNMP agent. One useful example of a trap is the linkDown trap. When the link state on an interface changes from up to down, the managed device, if configured to use traps, sends an SNMP packet indicating the change. The listening SNMP agent can then use this information to inform an operator.

Because a trap is sent over UDP, just like any other SNMP packet, there is no guarantee that it will make it to its destination. But the problem is somewhat worse for traps than for other types of SNMP requests. SNMP agents that make a query with get-request , get-next-request , or set-request can wait for a response, and if one does not arrive , it can try the query again. A device sending a trap, however, has no mechanism to determine if the trap was received.

Also remember that under certain circumstances, a device may not be able to send a trap. If it unexpectedly loses power, for example, it will not have any opportunity to send a message.



Open Source Network Administration
Linux Kernel in a Nutshell (In a Nutshell (OReilly))
ISBN: 130462101
EAN: 2147483647
Year: 2002
Pages: 85

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net