Charles M. Kozierok The TCP-IP Guide

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

On The Web: A full, hyperlinked list of RFCs can be found at: http://www.rfc-

editor.org/rfc-index.html

TCP/IP Structure of Management Information (SMI) and

Management Information Bases (MIBs)

The Internet Standard Management Framework defines three major components that

describe how devices can be managed on a TCP/IP internetwork. One of these, the actual

Simple Network Management Protocol (SNMP) is relatively well-known, but is only part of

the overall picture. SNMP describes how information is exchanged between SNMP entities,

but two other components are equally important because they describe the information

itself.

In this section I describe these two important supporting elements of the TCP/IP Internet

Standard Management Framework: the Management Information Base (MIB) standard that

describes types of information that SNMP works with, and the Structure of Management

Information (SMI) standard that specifies how MIB information is defined. Understanding

these two parts of the SNMP Framework is an important initial step before we examine the

actual SNMP protocol itself.

Since SMI and MIBs are so closely related, they are described in combination here. I begin

with an overview description of the SMI data description language and how management

information bases (MIBs) work. I discuss the MIB object name hierarchy and the notation

used to refer to names. I also describe how MIB objects work, discussing the different

object types and MIB object groups.

Background Information: If you have not yet already read the section describing

the SNMP Internet Standard Management Framework, you should do so before

proceeding here.

Note: I describe here MIB concepts common to all of the versions of SNMP, and

discuss both of the specific versions of SMI (SMIv1 and SMIv2) used in those

SNMP versions.

TCP/IP Structure of Management Information (SMI) and Management

Information Bases (MIBs) Overview

The key to really understanding TCP/IP network management is to comprehend the infor-

mation-oriented nature of the entire Internet Standard Management Framework (SNMP

Framework). To see what I mean by this, let's step back for a moment and consider in

general terms the problem of network management, and more specifically, the problem of

managing devices on a network.

Understanding SNMP's Information-Oriented Design

A network administrator needs to perform two basic types of actions: gather data about

devices to learn how they are functioning, and give commands to devices to change how

they are functioning. In the simplest terms, the first category can be considered like a “read”

operation, and the second is comparable to a “write” operation.

A classical way of implementing this functionality is to define a communication protocol.

Most such protocols are command-oriented—they consist of a specific set of commands to

perform the “read” and “write” operations we mentioned above. For example, a network

management protocol might have a read command such as “report on number of hours

device has been in use”, and a write command such as “put this device into test mode”. The

network manager would control the device by giving the appropriate commands.

A command-oriented management protocol has the advantage of simplicity: it's clear what

the commands are for and how they are to be used. It can be reasonably well-suited for use

in certain environments, but it doesn't work well on a large, heterogeneous TCP/IP inter-

network. The main reason for this is that command-orientation inextricably ties the protocol

to the devices being managed. Consider:

☯ Every type of device might require a distinct set of commands. For example, the

commands given to a router might need to be different than those given to a host. This

would lead either to a proliferation of commands in the protocol, or to inflexibility in

allowing proper management of different device types.

☯ Every time a company created a new type of device, or made a unique version of a

type of device, the network management protocol would have to be changed.

☯ Whenever the operation of a kind of device changed, due perhaps to a change in

another protocol, the management protocol would need to be updated.

☯ The protocol itself could not be easily changed without affecting a lot of hardware.

The solution to the problems of command-oriented management protocols was to use an

information-oriented model. Instead of defining specific commands that interrogate or

control devices, the devices are defined in terms of units of information that are to be

exchanged between the devices and a management station.

Instead of “read” commands and “write” commands, we have variables that can be “read” or

“written”. Take the two examples mentioned earlier. Instead of a command like “report on a

number of hours device has been in use”, the device keeps a variable called “number of

hours in use” and the network management station can “read” this as one of many

variables, with no need for a specific protocol command. Instead of a “write” command

called “put this device into test mode”, the device has a variable called “current mode”. The

network manager can change the mode of the device to “test” by changing the value of the

variable.

This difference may seem subtle, but it in fact underlies every aspect of how SNMP works. I

believe part of why the SNMP Framework is hard to understand is because insufficient

emphasis is placed on looking at things in the “SNMP way”, which means thinking about

information objects and not commands.

Key Concept: Unlike most protocols, which are command-oriented, SNMP is infor-

mation-oriented. SNMP operations are implemented using objects called variables

that are maintained in managed devices. Rather than issuing commands, a network

management station checks the status of a device by reading variables, and controls the

operation of the device by changing (writing) variables.

The Management Information Base (MIB) and MIB Objects

Given this backdrop, we can look at the SNMP Framework in a new light. The actual SNMP

protocol itself, which we'll examine in the next section, has only a few, generic commands to

accomplish “read” and “write” tasks as mentioned just above. It deals with only the methods

by which network management information is exchanged between SNMP agents and

SNMP network management stations. The network management information is really the

heart of TCP/IP network management.

So, instead of SNMP being defined in terms of commands used to control particular

devices, it is defined in terms of management information variables, generally called

objects. Each object describes a particular characteristic of a device. Some objects are

fairly generic and are meaningful for any device on a TCP/IP network; for example, an

object describing something related to the Internet Protocol itself, such as the device's IP

address. Other objects might be particular to a specific type of device; for example, a router

will have objects that a regular host's Ethernet network interface card would not.

A collection of objects used in SNMP is called a management information base, or MIB. (In

fact, SNMP objects are often called MIB objects.) The first version of SNMP, SNMPv1, had

a single standard that defined the entire MIB for SNMP. Newer versions however provide

more flexibility by using different MIB modules that defines sets of variables particular to the

hardware or software used by a device.

Defining objects using modules allows for significant flexibility in defining the variables that

allow management of different types of devices. A device can incorporate all the MIB

modules appropriate to the hardware and software it uses. For example, if you had a device

using Ethernet, it would incorporate variables from the Ethernet MIB; one using Token Ring

would use the Token Ring MIB. Both devices would also use the common SNMP MIB that is

used by all TCP/IP devices. Other modules might also be included as needed. We'll see

more of how this works later in this section.

Key Concept: The management data variables in a managed device are maintained

in a logical collection called a management information base (MIB). The objects in

the MIB are often called MIB objects, and are typically collected into sets called MIB

modules.

Defining MIB Objects: the Structure of Management Information (SMI)

The use of MIB objects solves the problem of the network management protocol being tied

to the network management information. However, we must be very particular about how

we define these objects. Again, the reason is the wide variety of devices that TCP/IP allows

to be connected together. Each device may represent information in a different way; for

them all to communicate with each other, we need to ensure that management information

is represented in a consistent manner.

The part of the SNMP Framework that ensures the universality of MIB objects is the

Structure of Management Information (SMI) standard. SMI defines the rules for how MIB

objects and MIB modules are constructed. In SMI, MIB objects are described using a

precise set of definitions based on a data description language called the ISO Abstract

Syntax Notation 1 (ASN.1) standard.

In essence then, we really have three “levels of abstraction” in SNMP. The actual SNMP

protocol moves values that represent the state of management devices. The MIB defines

what these variables are. And the SMI defines how the variables in the MIB are themselves

defined.

There are two main SMI standards. The original, SMIv1, was part of the first SNMP

Framework, SNMPv1, defined in RFC 1155. It sets out the basic rules for management

information bases and MIB variables. The second, SMIv2, was defined as part of SNMPv2p

in RFC 1442 and further updated in RFC 2578, part of SNMPv3. It is similar to the earlier

version but defines more object types as well as the structure of MIB modules.

These SMI standards are responsible for defining the following important information

elements in SNMP:

☯ The general characteristics associated with all MIB objects. SMI defines the standard

way by which all MIB objects are described.

☯ The different types of MIB objects that can be created, such as integers, strings and

more complex data types.

☯ A hierarchical structure for naming MIB objects, so they can be addressed in a

consistent manner without names overlapping.

☯ The information associated with each MIB module.

Key Concept: The Structure of Management Information (SMI) standard is respon-

sible for defining the rules for how MIB objects are structured, described and

organized. SMI allows dissimilar devices to communicate by ensuring that they use a

universal data representation for all management information.

In fact, the SMI and MIB standards are so closely related that it is hard to discuss one

without the other. The rest of this section discusses SNMP management information struc-

tures making reference to both SNMP Framework components. We'll see how MIB objects

are defined and the characteristics of each, and look at MIB data types, the structure used

to organize MIB objects, and the way MIB modules and object groups work.

Note: Due to its name, the management information base is often called a

“database”. This is, strictly speaking, inaccurate. The MIB is a description of

objects. The actual MIB in a device may be implemented as a software database,

but it need not be.

TCP/IP MIB Objects, Object Characteristics and Object Types

The Internet Standard Management Framework (SNMP Framework) is designed to facil-

itate the exchange of management information. The Management Information Base (MIB)

defines a device's management information. The MIB contains a number of variables called

MIB objects; they are also called managed objects. These objects are defined according to

the rules set out in the Structure of Management Information (SMI) standard.

The best place to begin looking at MIB objects is by examining the SMI rules that define

them. As I mentioned earlier in this section, two different versions of SMI have been

created: SMIv1 as part of the original SNMP, and SMIv2 as part of SNMPv2 and SNMPv3.

The two are similar in terms of how MIB objects are described, but SMIv2 allows more infor-

mation to be associated with each object.

MIB Object Mandatory Characteristics

Just as a typical protocol uses a field format for specifying the content of messages sent

between devices using the protocol, SMI uses a format that specifies the fundamental

characteristics of each MIB object. The most basic of these are five mandatory character-

istics defined in SMIv1. These are also used in SMIv2, but a couple of names were

changed, and the possible values for some of the fields were modified as well. This is

shown conceptually in Figure 272.

Object Name

Each object has a name that serves to uniquely identify it. Actually, that's not entirely true.

Each object actually has two names: a textual name called an Object Descriptor and a

numeric Object Identifier that indicates the object's place in the MIB object name hierarchy.

I'm sure that made no sense to you, but that's why I included the next topic discussing

object naming that hopefully will (make sense that is.)

Syntax

An object’s Syntax defines its data type and the structure that describes it. This attribute of

an MIB object is very important because it defines the data type of information that the

object contains. There are two basic categories of data types allowed:

☯ Regular Data Types: These are single pieces of information, of the type we are used

to dealing with on a regular basis; examples would be integers or strings. These are

called base types in SMIv2. SMIv1 differentiates between primitive types like integers

defined in ASN.1, and defined types that are special forms of primitive types that are

still single pieces of information but with certain special meaning attached to how they

are used. SMIv2 doesn't use those two terms.

Figure 272: SNMP Management Information Base (MIB)

This diagram shows an SNMP management information base containing “N” MIB objects. Each object has

five mandatory characteristics and a variable number of optional characteristics.

Object #1 Name Syntax

Access /

Max-Access

Status

Definition /

Description

Optional

Characteristics

Management Information Base (MIB)

Object #2 Name Syntax

Access /

Max-Access

Status

Definition /

Description

Optional

Characteristics

Object #3 Name Syntax

Access /

Max-Access

Status

Definition /

Description

Optional

Characteristics

Object #N Name Syntax

Access /

Max-Access

Status

Definition /

Description

Optional

Characteristics

☯ Tabular Data: A collection of multiple data elements. This may take the form of a list of

base types or a table of base types. For example, a table of integers could be

constructed to represent a set of values. In SMIv1 these are called constructor types;

in SMIv2 they are conceptual tables. They can be accessed using special SNMP

mechanisms designed for reading tables. See the topic on SNMP table traversal for

more on tables.

Access (Max-Access in SMIv2)

This field defines the ways that an SNMP application will normally use the object. In SMIv1,

there are four different possible values: read-only, read-write, write-only, and not-

accessible.

In SMIv2 there are five values, which are described as a hierarchy of sorts. SMIv2 calls this

characteristic Max-Access (maximum access) to make it explicit that higher access levels

include the lower levels as well. For example, an object with read-create access can also be

used in any of the modes “below it”, such as read-write, but not vice versa. Table 206 shows

the five SMIv2 access values, in decreasing order of access. Note that write-only has been

removed in SMIv2:

Status

Indicates the currency of the object definition. In SMIv1 there are three values: mandatory,

optional and obsolete. In SMIv2, the first two are combined into simply current, meaning a

current definition. The value obsolete is retained, and deprecated is added, meaning the

definition is obsolete but maintained for compatibility.

Definition (Description in SMIv2)

A textual description of the object.

Key Concept: Each management information variable, called a MIB object, has

associated with it five key attributes: its name, syntax, maximum access, status and

definition. It may also have a number of optional characteristics.

Table 206: SNMP SMI Version 2 Max-Access Values

Max-Access Value Description

read-create Object can be read, written or created.

read-write Object can be read or written.

read-only Object can only be read.

accessible-for-notify

Object can be used only using SNMP notifi-

cation (SNMP traps).

not-accessible Used for special purposes.

SMIv2 MIB Object Optional Characteristics

SMIv2 adds the following optional characteristics that may appear in the definition of an

object:

☯ Units: A text description of the units associated with the object.

☯ Reference: A text cross-reference to a related document or other information of

relevance to the object.

☯ Index: A value used to define objects that are actually more complex “rows” of other

objects.

☯ Augments: An alternative to the Index field.

☯ DefVal: Defines an acceptable default value for the object.

SMI Regular Data Types

Table 207 shows the regular data types supported for objects in both SMIv1 and SMIv2.

(The names with “32” in them are the ones used in SMIv2; they were changed to make the

type's bit size explicit.) The first five entries in the table are primitive types, the rest are

defined types, using the SMIv1 terminology.

Table 207: SNMP SMI Regular Data Types (Page 1 of 2)

Data Type

Code

Description SMIv1? SMIv2?

Integer /

Integer32

A 32-bit signed integer in two's complement notation, capable of

holding a value from -2,147,483,648 to +2,147,483,647. Can also

be used to represent an enumerated type; for example, where 1

represents a particular constant, 2 represents a different one, and

so on.

Yes Yes

Octet String A variable-length string of binary or text data. Yes Yes

Null Nothing. Yes —

Bits

An enumeration of named bits. Used to allow a set of bit flags to be

treated as a single data type.

— Yes

Unsigned A 32-bit unsigned integer, from 0 to 4,294,967,295. — Yes

Network

Address /

IpAddress

An IP address, encoded as a 4-byte octet string. Yes Yes

Counter /

Counter32

A 32-bit unsigned integer, that begins at 0 and increases up to

4,294,967,295, then wraps back to 0.

Yes Yes

Gauge /

Gauge32

A 32-bit unsigned integer, that may have a value from 0 to

4,294,967,295 and may increase or decrease, like a gauge. A

minimum and maximum value are associated with the gauge,

indicating its normal range.

Yes Yes

TimeTicks

A 32-bit unsigned integer that indicates the number of hundredths

of seconds since some arbitrary start date. Used for timestamping

and to compute elapsed time.

Yes Yes

SMIv2 Textual Conventions

In addition to these types, other defined types are also created to again, indicate more

specific semantics for a particular data type. These are called textual conventions and are

described in RFC 2579 for SMIv2. For example, a type called TimeStamp is defined which

is the same as TimeTicks. However, seeing an object using the former rather than the latter

makes it more clear that the variable is representing a particular time stamp value. Another

is called TimeInterval, which is also just an integer underneath its name, but conveys a

different interpreted meaning.

Example SMIv2 Object Definition

If all of the above seemed very confusing to you, note that this topic is in fact a significant

simplification of SMI's object definitions. SNMP is so much fun! If an example will help,

check out Table 208, which shows an object definition from RFC 3418, using SMIv2.

Note that DisplayString is a textual convention for a displayed text string. The last part,

“{ system 6 }”, will be explained in the next topic.

TCP/IP MIB Object Descriptors and Identifiers and the Object Name

Hierarchy and Name Notation

Of the many MIB object characteristics, only one is sufficiently interesting that it really

deserves its own exposition. Or perhaps I should say, only one is sufficiently complicated

that it does. ☺ This is the object name, part of the larger naming system used for MIB

objects.

Opaque

Data using arbitrary ASN.1 syntax that is to be passed between

devices without being interpreted. As in NFS's XDR, the term

“opaque” means that the data is treated like a “black box” whose

internal details cannot be seen.

Yes Yes

Counter64

A counter like Counter32 but 64 bits wide, allowing a value from 0

to 18,446,744,073,709,551,615.

—Yes

Table 208: Example SNMP SMIv2 Object Definition

sysLocation OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255))

MAX-ACCESS read-write

STATUS current

DESCRIPTION "The physical location of this node

(e.g., 'telephone closet, 3rd floor'). If the location is

unknown, the value is the zero-length string."

::= { system 6 }

Table 207: SNMP SMI Regular Data Types (Page 2 of 2)

Data Type

Code

Description SMIv1? SMIv2?