Charles M. Kozierok The TCP-IP Guide

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

SNMPv2 PDU Formats

The format of protocol data units in SNMPv2 is described in RFC 1905, and is similar to that

of SNMPv1. The format for all PDUs in SNMPv2 is the same, except for the GetBulkRe-

quest-PDU message. (Oddly, this includes the Trapv2-PDU message, even though the

Trap-PDU message in SNMPv1 used a distinct format).

SNMPv2 Common PDU Format

Table 219 and Figure 283 show this common PDU format. Table 220 contains a listing of

the different values for the Error Status field and how they are interpreted.

Table 219: SNMP Version 2 (SNMPv2) Common PDU Format (Page 1 of 2)

Field

Name

Syntax

Size

(bytes)

Description

PDU

Type

Integer

(Enumer

ated)

Request

Integer 4

Request Identifier: A number used to match requests with replies. It is

generated by the device that sends a request and copied into this field in a

Response-PDU by the responding SNMP entity.

Error

Status

Integer

(Enumer

ated)

Error Status: An integer value that is used in a Response-PDU to tell the

requesting SNMP entity the result of its request. A value of zero indicates

that no error occurred; the other values indicate what sort of error

happened.

Note that the first six values (0 to 5) are maintained as used in SNMPv1 for

compatibility, but SNMPv2 adds many new error codes that provide more

specific indication of the exact nature of an error in a request. The genErr

code is still used only when none of specific error types (either the old

codes or the new ones) apply.

Since there are so many different Error Status codes, I have listed them

separately in Table 220.

PDU Type: An integer value that indicates the PDU type:

PDU Type

Value

PDU Type

0 GetRequest-PDU

1 GetNextRequest-PDU

2 Response-PDU

3 SetRequest-PDU

Obsolete, not used (this was the

old Trap-PDU in SNMPv1)

GetBulkRequest-PDU

(has its own format, see below)

6 InformRequest-PDU

7 Trapv2-PDU

8 Report-PDU

Error

Index

Integer 4

Error Index: When Error Status is non-zero, this field contains a pointer

that specifies which object generated the error. Always zero in a request.

Variable

Bindings

Variable Variable

Variable Bindings: A set of name-value pairs identifying the MIB objects

in the PDU, and in the case of messages other than requests, containing

their values. See the general message format topic for more on these

bindings.

Table 220: SNMP Version 2 (SNMPv2) PDU Error Status Field Values (Page 1 of 2)

Error

Status

Value

Error Code Description

0 noError

No error occurred. This code is also used in all request PDUs, since they have

no error status to report.

1 tooBig The size of the Response-PDU would be too large to transport.

2 noSuchName The name of a requested object was not found.

3 badValue

A value in the request didn't match the structure that the recipient of the

request had for the object. For example, an object in the request was specified

with an incorrect length or type.

4 readOnly

An attempt was made to set a variable that has an Access value indicating

that it is read-only.

5 genErr

An error occurred other than one indicated by a more specific error code in

this table.

6 noAccess Access was denied to the object for security reasons.

7 wrongType The object type in a variable binding is incorrect for the object.

8 wrongLength A variable binding specifies a length incorrect for the object.

9 wrongEncoding A variable binding specifies an encoding incorrect for the object.

10 wrongValue The value given in a variable binding is not possible for the object.

11 noCreation A specified variable does not exist and cannot be created.

12 inconsistentValue

A variable binding specifies a value that could be held by the variable but

cannot be assigned to it at this time.

resource-

Unavailable

An attempt to set a variable required a resource that is not available.

14 commitFailed An attempt to set a particular variable failed.

15 undoFailed

An attempt to set a particular variable as part of a group of variables failed,

and the attempt to then undo the setting of other variables was not successful.

authorization-

Error

A problem occurred in authorization.

Table 219: SNMP Version 2 (SNMPv2) Common PDU Format (Page 2 of 2)

Field

Name

Syntax

Size

(bytes)

Description

SNMPv2 GetBulkRequest-PDU Format

The special format of the SNMPv2 GetBulkRequest-PDU message is shown in Table 221

and Figure 284.

17 notWritable The variable cannot be written or created.

inconsis-

tentName

The name in a variable binding specifies a variable that does not exist.

Figure 283: SNMP Version 2 (SNMPv2) Common PDU Format

Table 221: SNMP Version 2 (SNMPv2) GetBulkRequest-PDU Format (Page 1 of 2)

Field Name Syntax

Size

(bytes)

Description

PDU Type

Integer

(Enumera

ted)

PDU Type: An integer value that indicates the PDU type, which is

5 for a GetBulkRequest-PDU message.

Request ID Integer 4

Request Identifier: A number used to match requests with replies.

It is generated by the device that sends a request and copied into

this field in a Response-PDU by the responding SNMP entity.

Non

Repeaters

Integer 4

Non Repeaters: Specifies the number of non-repeating, regular

objects at the start of the variable list in the request.

Table 220: SNMP Version 2 (SNMPv2) PDU Error Status Field Values (Page 2 of 2)

Error

Status

Value

Error Code Description

PDU Type

Request Identifier

Error Status

Error Index

PDU Variable Bindings

4 8 12 16 20 24 28 320

Note: The topic on SNMP table traversal contains full details on how Non

Repeaters and Max Repetitions are used.

SNMP Version 3 (SNMPv3) Message Format

In the late 1990s, SNMP version 3 was created to resolve the problems that occurred with

the many different variations of SNMPv2. The SNMPv3 Framework adopts many compo-

nents that were created in SNMPv2, including the SNMPv2 protocol operations, PDU types

and PDU format. Amongst the significant changes made in SNMPv3 include a more flexible

way of defining security methods and parameters, to allow the coexistence of multiple

security techniques.

Max

Repetitions

Integer 4

Max Repetitions: The number of iterations in the table to be read

for the repeating objects that follow the non-repeating objects.

Variable

Bindings

Variable Variable

Variable Bindings: A set of name-value pairs identifying the MIB

objects in the PDU. See the general message format topic for

more on these bindings.

Figure 284: SNMP Version 2 (SNMPv2) GetBulkRequest-PDU Format

Table 221: SNMP Version 2 (SNMPv2) GetBulkRequest-PDU Format (Page 2 of 2)

Field Name Syntax

Size

(bytes)

Description

PDU Type

Request Identifier

Non Repeaters

Max Repetitions

PDU Variable Bindings

4 8 12 16 20 24 28 320

The general message format for SNMPv3 still follows the same idea of an overall message

“wrapper” that contains a header and an encapsulated PDU. However, in version 3 this

concept is further refined. The fields in the header have themselves been divided into those

dealing with security and those that do not deal with security matters. The “non-security”

fields are common to all SNMPv3 implementations, while the use of the security fields can

be tailored by each SNMPv3 security model, and processed by the module in an SNMP

entity that deals with security. This solution provides considerable flexibility while avoiding

the problems that plagued SNMPv2.

The overall SNMPv3 message format is described in RFC 3412, which describes version 3

message processing and dispatching. It is shown in Table 222 and Figure 285.

Figure 285: SNMP Version 3 (SNMPv3) General Message Format

Message Version Number = 3

Message Identifier

Maximum Message Size

Message Flags

Message Security Model

(bytes 1 to 3)

Message Security

Model (byte 4)

PDU Variable Bindings

4 8 12 16 20 24 28 320

Message Body (PDU)

Message Security Parameters

Reserved

Reportable

Flag

Pr iv ac y

Flag

(Priv)

Authen-

tication

Flag

(Auth)

24680

Scoped PDU

Context Engine ID

Context Name

PDU Control Fields

Table 222: SNMP Version 3 (SNMPv3) General Message Format (Page 1 of 2)

Field Name Syntax

Size

(bytes)

Description

Msg Version Integer 4

Message Version Number: Describes the SNMP version number

of this message; used for ensuring compatibility between versions.

For SNMPv3, this value is 3.

Msg ID Integer 4

Message Identifier: A number used to identify an SNMPv3

message and to match response messages to request messages.

The use of this field is similar to that of the Request ID field in the

PDU format (see Table 219), but they are not identical. This field

was created to allow matching at the message processing level

regardless of the contents of the PDU, to protect against certain

security attacks. Thus, Msg ID and Request ID are used

independently.

Msg Max

Size

Integer 4

Maximum Message Size: The maximum size of message that the

sender of this message can receive. Minimum value of this field is

484.

Msg Flags

Octet

String

Msg Security

Model

Integer 4

Message Security Model: An integer value indicating which

security model was used for this message. For the user-based

security model (the default in SNMPv3) this value is 3.

essage

ags:

ags

con

s process

ng o

message. The current substructure of this field is:

Subfield

Name

Size

(bytes)

Description

Reserved

5/8

(5 bits)

Reserved: Reserved for future use.

Reportable

Flag

1/8

(1 bit)

Reportable Flag: When set to 1, a device

receiving this message must send back a

Report-PDU whenever conditions arise

where such a PDU should be generated.

Priv Flag

1/8

(1 bit)

Privacy Flag: When set to 1, indicates that

encryption was used to protect the privacy

of the message. May not be set to 1 unless

Auth Flag is also set to 1.

Auth Flag

1/8

(1 bit)

Authentication Flag: When set to 1,

indicates that authentication was used to

protect the authenticity of this message.

And now, let's look at the PDU format for SNMPv3. Ah ha! We are spared this, because

SNMPv3 uses the protocol operations from SNMPv2; this is described in RFC 3416, which

is just an update of RFC 1904. Thus, the PDU formats are the same as in the previous

topic. Phew!

Msg Security

Parameters

— Variable

Message Security Parameters: A set of fields that contain

parameters required to implement the particular security model

used for this message. The contents of this field are specified in

each document describing an SNMPv3 security model. For

example, the parameters for the user-based model are in RFC

3414.

Scoped PDU — Variable

Table 222: SNMP Version 3 (SNMPv3) General Message Format (Page 2 of 2)

Field Name Syntax

Size

(bytes)

Description

cope

PDU

ransm

itt

, a

ong w

ith

parameters that identify an SNMP context, which describes a set of

management information accessible by a particular entity. The

PDU is said to be “scoped” because it is applied within the scope of

this context. (Yeah, security stuff is confusing, sorry; it would take

pages and pages to properly explain contexts; see RFC 3411.) The

field may be encrypted or unencrypted depending on the value of

Priv Flag and its structure is:

Subfield

Name

Syntax

Size

(bytes)

Description

Context

Engine ID

Octet

String

Variable

Context Engine ID: Used to

identify to which application the

PDU will be sent for processing.

Context

Name

Octet

String

Variable

Context Name: An object identifier

specifying the particular context

associated with this PDU.

PDU — Variable

PDU: The protocol data unit being

transmitted.

TCP/IP Remote Network Monitoring (RMON)

The Simple Network Management Protocol (SNMP) defines both a framework and a

specific protocol for exchanging network information on a TCP/IP internetwork. The general

model used by SNMP is that of a network management station (NMS) that sends requests

to SNMP agents running on managed devices. The SNMP agents may also initiate certain

types of communication by sending trap messages to tell the NMS when particular events

occur.

This model works well, which is why SNMP has become so popular. However, one funda-

mental limitation of the protocol and the model it uses is that it is oriented around the

communication of network information from SNMP agents that are normally part of regular

TCP/IP devices, such as hosts and routers. The amount of information gathered by these

devices is usually somewhat limited, because obviously hosts and routers have “real work

to do”—that is, doing the jobs of being hosts and routers. They can't devote themselves to

network management tasks.

Thus, in situations where more information is needed about a network than is gathered by

traditional devices, administrators often use special hardware units called network

analyzers, monitors or probes. These are dedicated pieces of equipment that are

connected to a network and used strictly for the purpose of gathering statistics and

watching for events of interest or concern to the administrator. It would obviously be very

useful if these devices could use SNMP to allow the information they gather to be retrieved,

and to let them generate traps when they notice something important.

To enable this, the Remote Network Monitoring (RMON) specification was created. RMON

is often called a protocol, and you will sometimes see SNMP and RMON referred to as “the

TCP/IP network management protocols”. However, RMON really isn't a separate protocol at

all—it defines no protocol operations. RMON is in fact part of SNMP, and the RMON speci-

fication is simply a management information base (MIB) module that defines a particular set

of MIB objects for use by network monitoring probes. Architecturally, it is just one of the

many MIB modules that comprise the SNMP Framework.

Key Concept: SNMP Remote Network Monitoring (RMON) was created to enable

the efficient management of networks using dedicated management devices such as

network analyzers, monitors or probes. RMON is often called a “protocol”, but does

not in fact define any new protocol operations; it is a MIB module for SNMP that describes

objects that permit advanced network management capabilities.

RMON Standards

The first standard documenting RMON was RFC 1271, Remote Network Monitoring

Management Information Base, published in 1991. RFC 1271 was replaced by RFC 1757 in

1995, which made a couple of changes to the specification. RFC 2819, May 2000, updates

RMON to use the new Structure of Management Information version 2 (SMIv2) specification

that is part of SNMPv2 but is functionally the same as RFC 1757.

RMON MIB Hierarchy and Object Groups

Since RMON is a MIB module, it consists almost entirely of descriptions for MIB objects,

with each having the standard characteristics belonging to all such objects. All the objects

within RMON are arranged into the SNMP object name hierarchy within the rmon group,

which is group number 16 within the SNMP mib (mib-2) object tree, 1.3.6.1.2.1. So, all

RMON objects have identifiers starting with 1.3.6.1.2.1.16. This single RMON group is

broken down into several lower-level groups that provide more structure for the RMON

objects defined by the specification. Figure 286 shows this structure.

Figure 286: SNMP Remote Network Monitoring (RMON) MIB Hierarchy

RMON uses a special MIB module, rmon(16), which fits into the overall SNMP object hierarchy tree under

mib/mib-2(1) within mgmt(2)—just like other MIB object groups such as sys(1) and if(2); see Figure 273.

Within this group, which has the group identifier 1.3.6.1.2.1.16, are 9 subgroups of RMON objects.

statistics(1)

...

mgmt(2)

{1 3 6 1 2}

mib/mib-2(1)

{1 3 6 1 2 1}

history(2) alarm(3) hosts(4)

hostsTopN(5)

matrix(6) filter(7) capture(8) event(9)

rmon(16)

{1 3 6 1 2 1 16}

......