Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

The first version of the SNMP Framework, SNMPv1, included the first formal definition of

the SNMP Protocol, in RFC 1067 (later revised by RFCs 1098 and 1157). This standard

refines the protocol operations given in the SGMP document. It makes the operation of the

SNMP Protocol fit into the overall SNMP Framework, working with formally-defined MIB

objects.

SNMPv2 and the Division of SNMP into Protocol Operations and Transport Mappings

When SNMPv2 was created, the single document describing the SNMP Protocol was split

into two standards, to make the protocol more modular and better reflective of the layers

used in internetworks. This division has been maintained in SNMPv3 as well. The two types

of documents specify the following:

☯ Protocol Operations: The first document of the pair describes the actual mechanics

by which MIB objects are moved between SNMP devices using particular SNMP

message types. In SNMPv3 it is RFC 3416, Version 2 of the Protocol Operations for

the Simple Network Management Protocol (SNMP). When people talk about just “the

SNMP standard”, this is the document they usually mean.

☯ Transport Mappings: The second document details how the SNMP protocol opera-

tions described in the first standard above can be transported over a variety of different

protocol suites. By using the correct mapping, SNMP operations can be carried out

using lower-layer technologies other than IP. This standard is represented in SNMPv3

by RFC 3417, Transport Mappings for the Simple Network Management Protocol

(SNMP).

I discuss transport mappings in a little more detail in the topic on SNMP messaging, but

since IP/UDP is by far the most common transport mechanism, there isn't a great deal to

say about that aspect of the SNMP Protocol. The focus of most of our look at SNMP will

concentrate on SNMP protocol operations: what messages are used, how they are struc-

tured and how they are exchanged. In examining these messages we will see the two main

ways that information exchanges occur in SNMP (by polling and by interrupt) and also

discover how the SNMP Protocol works with MIB objects.

Key Concept: The actual mechanism used to communicate management infor-

mation between network management stations and managed devices is called the

Simple Network Management Protocol, which may be called the SNMP Protocol to

differentiate it from the SNMP Framework. It consists of a number of protocol operations

that describe the actual message exchanges that take place between devices, and a set of

transport mappings that define how these messages are carried over various types of inter-

networks. The Internet Protocol is the most common transport mapping used for SNMP.

SNMP Protocol Operations

The Simple Network Management Protocol (SNMP) is the protocol responsible for allowing

network management stations on a TCP/IP internetwork to perform management tasks with

managed devices. The core of the protocol consists of a set of protocol operations that

allow management information to be exchanged between SNMP agents and managers.

Having previously examined the generalities of SNMP and what MIB objects are, we can

now get down to the “nitty gritty” of how management information is actually communicated

using SNMP. Yes, finally you get to actually see how SNMP “works”.

In this section I provide a detailed description of the operations performed by the SNMP

Protocol. I begin with a general description of how SNMP operates and the two basic

methods devices use to communicate; I also describe SNMP's message classes. I then

provide topics that describe in detail each of the basic operations performed in SNMP and

the messages used for those purposes: basic request/response, table traversal, object

modification, and notification. I conclude with a discussion of SNMP security issues and a

summary of the security methods in each of the SNMP versions.

Note that the number and types of protocol operations in SNMP changed between SNMPv1

and SNMPv2. The operations defined in SNMPv2 have been carried forward into the

newest version, SNMPv3. Most of the discussion focuses on SNMPv3 as the newest imple-

mentation, while mentioning what differences there are between it and the original and still

widely-used SNMPv1.

SNMP Protocol General Operation, Communication Methods and Message

Classes

The main function of the SNMP Protocol is to allow management information, in the form of

Management Information Base (MIB) objects, to be communicated between SNMP-capable

devices. The protocol operations of the SNMP Protocol are what describe how this commu-

nication is performed. Before looking at these operations individually in detail, it is

instructive to take an overall look at information exchange methods used in SNMP.

SNMP Communication Methods

For SNMP to be useful in enabling the management of a network, it must allow a network

administrator using a network management station (NMS) to easily check the status of

SNMP agents in managed devices. In data communications, there are two general

techniques that are used in a situation where one entity needs to be kept informed about

activity or occurrences on another:

☯ Poll-Driven: This term refers to the general technique of having the one who wants

the information ask for it; just like someone might conduct a political poll. In SNMP, the

NMS would poll SNMP agents for information. A common “real life” example of polling

is the model used by the regular mail service; every day you go to check your mailbox

to see if you have any mail.

☯ Interrupt-Driven: This term refers to having a device with information that another

needs to know decide to send the information of its own “volition”. In SNMP, this would

refer to an SNMP agent sending information to an NMS without being asked. This is

the model used by that most famous of “interrupters”, the telephone.

Which is “better”? My quotation marks give me away again. The usual answer applies here:

neither is better nor worse universally, which is why both options exist. Due to the obvious

strengths and weaknesses of these models, The SNMP Protocol is designed to use both.

Polling is used for the periodic gathering of routine information, such as checking the usage

statistics and general status of a device. Interrupts are used in the form of traps that a

network administrator can set on a managed device. These traps cause an SNMP agent to

interrupt an NMS when an event of import occurs.

Key Concept: SNMP uses two basic methods for exchanging management infor-

mation. Routine communication uses a poll-driven technique, where the network

management station requests information from managed nodes. An interrupt-driven

model is also supported: in situations where a managed device needs to tell a management

station immediately about an occurrence, it can send a trap message without waiting for a

request from the management station.

SNMP Messages and Protocol Data Units (PDUs)

The actual communication of information in the SNMP Protocol is performed in a manner

similar to most other protocols, through the exchange of SNMP messages. These

messages are sometimes called protocol data units or PDUs. This is a term you may have

heard used in other protocols, and is also part of the formal definition of data encapsulation

in the OSI Reference Model. A message is, of course, a “data unit” used by the “protocol”.

SNMP messages all have “-PDU” at the ends of their names to identify them.

Some consider “protocol data unit” to be analogous to the military using “oblong metallic-

headed manually-operated fastener acceleration device” to refer to a hammer. To be fair

though, strictly speaking, in SMNP a PDU and a message are not exactly the same. The

PDU is the higher-layer data that SNMP encapsulates, as described by the OSI model. The

SNMP message format is a wrapper that encapsulates a PDU along with header fields, as I

describe in the section on SNMP messaging. However, the point of a message is to send a

PDU, so the two are “close enough”, and the terms are sometimes used interchangeably.

SNMP PDU Classes

SNMPv1 originally defined six PDUs. The number of PDUs was expanded and some

changes made to their name and use in SNMPv2 and SNMPv3. The current SNMP

Framework categorizes the PDUs into different classes. These classes describe both the

function of each message type and the kind of communication they use to perform their task

(polling versus interrupting).

Table 211 shows the main SNMPv2/SNMPv3 PDU classes, describes them, and shows

which PDUs are in each class in SNMPv2/SNMPv3. These classes were not used in

SNMPv1 but for clarity I also show which messages from SNMPv1 fall into the classes

conceptually:

The GetBulkRequest-PDU and InformRequest-PDU messages are new in SNMPv2/v3.

The GetResponse-PDU message was renamed just Response-PDU (since it is in fact a

response and not a message that “gets” anything), and the new Trapv2-PDU replaces Trap-

PDU.

There are three other “special” classes defined by the current SNMP Framework that are of

less interest to us because they don't define actively-used messages, but which I should

mention for completeness. The Internal class contains a special message called Report-

PDU defined for internal SNMP communication. The SNMP standards also provide two

classes called Confirmed and Unconfirmed, used to categorize the messages in my table

above based on whether or not they are acknowledged. The Report-PDU, Trapv2-PDU,

and Response-PDU messages are considered Unconfirmed and the rest are Confirmed.

The next few topics will show how the major message types in the four main classes are

used. Note that in general terms, all protocol exchanges in SNMP are described in terms of

one SNMP entity sending messages to another. Most commonly, the entity sending

requests is an SNMP manager and the one responding an SNMP agent, except for traps,

which are sent by agents. For greater clarity, I try to use these more specific terms

(manager or agent) when possible, rather than just “entity”.

Key Concept: SNMP messages consist of a set of fields wrapped around a data

element called a protocol data unit or PDU. In some cases, the terms “message” and

“PDU” are used interchangeably, though they are technically not the same. SNMP

PDUs are arranged into classes based on their function.

Table 211: SNMP PDU (Message) Classes

SNMPv3

PDU Class

Description SNMPv1 PDUs

SNMPv2/SNMPv3

PDUs

Read

Messages that read management

information from a managed device

using a polling mechanism.

GetRequest-PDU,

GetNextRequest-PDU

GetRequest-PDU,

GetNextRequest-PDU,

GetBulkRequest-PDU

Write

Messages that change management

information on a managed device to

affect the device's operation.

SetRequest-PDU SetRequest-PDU

Response

Messages sent in response to a

previous request.

GetResponse-PDU Response-PDU

Notification

Messages used by a device to send

an interrupt-like notification to an

SNMP manager.

Trap-PDU

Trapv2-PDU,

InformRequest-PDU

SNMP Protocol Basic Request/Response Information Poll Using GetRequest

and (Get)Response Messages

The obvious place to begin our detailed look at SNMP protocol operations is with the

simplest type of information exchange. This would be a simple poll operation to read one or

more management information variables, used by one SNMP entity (typically an SNMP

manager) to request or read information from another entity (normally an SNMP agent on a

managed device). SNMP implements this as a simple two-message request/response

protocol exchange, similar the request/reply processes found in so many TCP/IP protocols.

This information request process typically begins with the user of an application wanting to

check the status of a device or look at information about it. As we've seen, all this infor-

mation is stored on the device in the form of MIB objects. The communication, therefore,

takes the form of a request for particular MIB objects and a reply from the device containing

those objects' values. In simplified form, the steps in the process are as follows (and as

shown in Figure 274):

1. SNMP Manager Creates GetRequest-PDU: Based on the information required by the

application and user, the SNMP software on the network management station creates

a GetRequest-PDU message. It contains the names of the MIB objects whose values

the application wants to retrieve.

2. SNMP Manager Sends GetRequest-PDU: The SNMP manager sends the PDU to

the device that is being polled.

3. SNMP Agent Receives and Processes GetRequest-PDU: The SNMP agent

receives and processes the request. It looks at the list of MIB object names contained

in the message and checks to see if they are valid (ones the agent actually imple-

ments). It looks up the value of each variable that was correctly specified.

4. SNMP Agent Creates Response-PDU: The agent creates a Response-PDU to send

back to the SNMP Manager. This message contains the values of the MIB objects

requested and/or error codes to indicate any problems with the request, such as an

invalid object name.

5. SNMP Agent Sends Response-PDU: The agent sends the response back to the

SNMP Manager.

6. SNMP Manager Processes Response-PDU: The manager processes the infor-

mation in the Response-PDU received from the agent.

Key Concept: The most basic type of communication in SNMP is an information

poll, which allows a network management station to read one or more MIB objects

from a managed node using a simple request/reply message exchange.

The Response-PDU message is called GetResponse-PDU in SNMPv1. Presumably, this

name was chosen from the fact that it was a response to a get operation, to make the

names GetRequest-PDU and GetResponse-PDU somewhat symmetric. The problem is

that this name is confusing, for two reasons. First, it sounds to some people like the

purpose of the PDU is to “get a response”. Second, the GetResponse-PDU was also

defined as the response message for operations other than “gets”, including the reply

message for SetRequest-PDU. Having a “GetResponse” message be sent in reply to a

“SetRequest” is disconcerting; the new name is more generic and avoids these problems.

SNMP Protocol Table Traversal Using GetNextRequest and GetBulkRequest

Messages

The GetRequest-PDU message we examined last topic is the one used by applications to

request values for regular, single variables in an SNMP managed object's management

information base. As I mentioned in the topic describing MIB objects, however, the Structure

of Management Information (SMI) also allows a management information base to contain

tabular data.

MIB tables are a useful way for a device to store and organize a set of related data items. It

would be rather inefficient to try to structure these items just as collections of regular

objects. For example, a device may have multiple IP addresses. It would be inefficient to

define one MIB object called ipAddr1, and another called ipAddr2, and so on to store IP

address information. Instead, an object called ipAddrTable is defined in the original

SNMPv1 MIB, which specifies a table containing one or more entries called ipAddrEntry.

Each entry contains the IP address and subnet mask for one of the interfaces of the device.

Figure 274: SNMP Information Poll Process

The basic SNMP information polling process involves a simple exchange of a GetRequest-PDU sent by an

SNMP manager and a Response-PDU returned by an SNMP agent.

SNMP Manager

GetRequest-PDU

1. Create

GetRequest-PDU Me ssa ge

3. Receive and Process

GetRequest-PDU Me ssa ge

4. Generate Response-PDU

Me ssa ge

SNMP Agent

5. Send Response-PDU

Me ssa ge

6. Process

Response-PDU Me ssa ge

2. Send

GetRequest-PDU Me ssa ge

Response-PDU

SNMPv1 Table Traversal Using GetNextRequest

There needs to be a way to let an SNMP manager may wish to read the contents of these

tables from a device. This can be done using the regular GetRequest-PDU message, by

specifying each entry in the table one after the other. However, this is somewhat crude, and

it leaves a problem: the SNMP manager may not know how many entries are in the table,

and therefore, how many entries it should request.

The problem of table traversal was addressed in SNMPv1 through the creation of a new

message type called GetNextRequest-PDU. You can think of this as a “relative” version of

the regular GetRequest-PDU. The GetNextRequest-PDU contains the name of a tabular

variable, as well as a particular entry in the table. The device receiving the GetNextRe-

quest-PDU uses this to look up the next value in the table and return it in a GetResponse-

PDU message.

The actual protocol exchange is about the same as that described in the previous topic: a

request is sent by the SNMP manager and a reply returned by the SNMP agent. The

difference is that instead of the SNMP agent returning the value for the variable specified, it

returns the value of the next variable in the table. This is then used as the value for the next

request, and so on, until the last entry in the table is reached. Once this happens and a

GetNextRequest-PDU is sent that contains this last entry, the responding device indicates

this by returning the MIB object that conceptually follows the table in the implementation of

the management information base. This signals to the SNMP manager that the table has

been fully traversed.

Key Concept: The SNMP GetNextRequest-PDU message allows a network

management station to request a series of consecutive variables in a management

information base. This is most commonly used to allow tabular data to be more easily

retrieved without requiring that each variable in the table be individually specified.

SNMPv2/v3 Table Traversal Using GetBulkRequest

The GetNextRequest-PDU message is functional, but while it is more elegant than using

regular GetRequest-PDU messages, it is not any more efficient—each entry in the table

must still be requested one at a time. This means that retrieving the information in a table

takes a long time, and also results in a great deal of traffic being generated due to the

number of requests and replies that must be sent.

To make table traversal easier and more conservative of network resources, SNMPv2 intro-

duced a new message type called GetBulkRequest-PDU. You can probably surmise the

idea here from the name. Instead of specifying a particular MIB object to get or to “get next”,

a GetBulkRequest-PDU allows an SNMP manager to send a single request that results in a

number of entries in a table being returned in a Response-PDU message.

The GetBulkRequest-PDU is designed to allow both regular variable and tables to be

retrieved in a single request. The PDU includes a list of objects, just as in a GetRequest-

PDU or GetNextRequest-PDU. The list is organized so that regular objects appear first and

table objects come afterwards. Two special parameters are included in the request, called

Non Repeaters and Max Repetitions. The first of these specifies the number of non-

repeating, regular objects to be retrieved; this is the number of regular objects at the start of

the object list. The second specifies the number of iterations, or entries, to read for the

remaining tabular objects.

For example, suppose an SNMP manager wanted to request 4 regular variables and 3

entries from a table. The GetNextRequest-PDU would contain five MIB object specifica-

tions, with the table last. The Non Repeaters field would be set to 4, and the Max

Repetitions field set to 3.

The original method of traversing tables using GetRequest-PDU and GetNextRequest-PDU

from SNMPv1 was retained in SNMPv2 and SNMPv3 when they were developed. However,

the introduction of the more efficient GetBulkRequest-PDU means that GetNextRequest-

PDU is not as important as it was in SNMPv1. Bear in mind, however, that using

GetBulkRequest-PDU does require that the requesting entity know how many entries to ask

for. So, some “trial and error” or multiple requests may be required to get a whole table if the

number of entries is not known.

Key Concept: To improve the efficiency of table traversal, SNMPv2 introduced the

GetBulkRequest-PDU message, which allows a network management station to

request a sequence of MIB objects from a table using a single request to a managed

node.

SNMP Protocol Object Modification Using SetRequest Messages

The GetRequest-PDU, GetNextRequest-PDU, and GetBulkRequest-PDU messages are

the three members of the SNMP “Read” class of PDUs—they are used to let an SNMP

manager read MIB objects from an MIB agent. The opposite function is represented by the

SNMP “Write” class, which contains a single member: the SNMP SetRequest-PDU

message.

The use of this PDU is fairly obvious; where one of the three Get PDUs specifies a variable

whose value is to be retrieved, the SetRequest-PDU message contains a specification for

variables whose values are to be modified by the network administrator. Remember that

SNMP does not include specific commands to let a network administrator control a

managed device. This is in fact the “control method”, by setting variables that affect the

operation of the managed device.

The set process is the complement of the get process; the same basic idea, pretty much,

but a reversal in how the object values “travel” and what is done with them. The process

follows these steps (see Figure 275):

1. SNMP Manager Creates SetRequest-PDU: Based on the information changes

specified by the user through the SNMP application, the SNMP software on the

network management station creates a SetRequest-PDU message. It contains a set of

MIB object names and the values to which they are to be set.

2. SNMP Manager Sends SetRequest-PDU: The SNMP manager sends the PDU to the

device being controlled.

3. SNMP Agent Receives and Processes SetRequest-PDU: The SNMP agent

receives and processes the set request. It examines each object in the request along

with the value to which the object is to be set, and determines if the request should or

should not be honored.

4. SNMP Agent Makes Changes and Creates Response-PDU: Assuming that the

information in the request was correct (and any security provisions have been

satisfied), the SNMP agent makes changes to its internal variables. The agent creates

a Response-PDU to send back to the SNMP Manager, which either indicates that the

request succeeded, or contains error codes to indicate any problems with the request

found during processing.

5. SNMP Agent Sends Response-PDU: The agent sends the response back to the

SNMP Manager.

6. SNMP Manager Processes Response-PDU: The manager processes the infor-

mation in the Response-PDU to see the results of the set.

Figure 275: SNMP Object Modification Process

The communication process for setting a MIB object value is very similar to that used for reading one. The

main difference is that, of course, the object values are sent from the SNMP Manager to the SNMP Agent,

carried in the SetRequest-PDU message.

SNMP Manager

SetRequest-PDU

1. Create

SetRequest-PDU M e ssa ge

3. Receive and Process

SetRequest-PDU Me ssa ge

4. Make Changes, Create

Response-PDU Me ssa ge

SNMP Agent

5. Send Response-PDU

Me ssa ge

6. Process

Response-PDU Me ssa ge

2. Send

SetRequest-PDU M e ssa ge

Response-PDU

Verification of Object Modification Requests

Obviously, telling a device to change a variable's value is a more significant request than

just asking the device to read the value. For this reason, the managed device must very

carefully analyze and verify the information in the request to ensure that the request is valid.

The checks performed include:

☯ Verifying the names of the objects to be changed.

☯ Verifying that the objects are allowed to be modified (based on their Access or Max-

Access object characteristic.)

☯ Checking the value included in the request to ensure that its type and size are valid for

the object to be changed.

This is also a place where general protocol security issues become more important.

Key Concept: SNMP network management stations control the operation of

managed devices by changing MIB objects on those devices. This is done using the

SetRequest-PDU message, which specifies the objects to be modified and their

values.

SNMP Protocol Information Notification Using Trap(v2) and InformRequest

Messages

The first topic in this section introduced the two basic methods of communicating infor-

mation between SNMP devices: using polls or interrupts. All of the message types and

exchanges we have examined thus far in this section have been poll-driven: they consist of

an SNMP manager making a specific request that results in action being taken, and a

response being generated by an SNMP agent.

The Need for Traps in SNMP

Polling is ideal for the exchange of routine information that needs to be gathered on a

regular basis. For example, the regular Get requests could be used to verify the settings on

a device, examine error counts over a period of time, or check its up-time or use statistics.

And obviously, polling is the only real method for performing a Set operation, where data is

changed.

But polling is not well-suited for important information that needs to be communicated

quickly. The reason is that poll-driven communication is always initiated by the recipient of

the information: the SNMP manager. If something significant occurs on a managed device

that the manager wasn't expecting, the manager won't find out about it unless it specifically

asks to see the variable that has changed. This means that important variables would need

to be checked all the time by the SNMP manager, which is highly efficient.