Charles M. Kozierok The TCP-IP Guide

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

As I said before, each MIB object actually has two names: an object descriptor and an

object identifier. The object descriptor is a conventional text name that provides a “user-

friendly handle” to refer to the object. The name is assigned based on the particular MIB

object group in which the object is located. In the example definition I gave at the end of the

prior topic, sysLocation is the object descriptor for that MIB object. I describe these names

in greater detail in the next topic, on MIB modules and object groups.

The MIB Object Name Hierarchy

Text names are convenient, but they are generally unstructured. There are at present over

10,000 different MIB objects, and even if each has a distinct text name, a huge collection of

such names doesn't help us to manage these objects and see how they are related. For

this, we need a more structured approach to categorizing and naming objects.

This problem is similar to another problem that you may recall reading about: the problem of

how to assign names on the Internet. Originally names for hosts were simple, “flat” names,

but this quickly grew unwieldy. The Domain Name System (DNS) formalized a structured

hierarchy for domain names. The DNS hierarchical name space allows every device to be

arranged into a single hierarchical tree structure. The name of the device can be formed by

traversing the tree from the top down to the location of the device, listing the labels

traversed separated by dots. For example, the Web server of The PC Guide is at

“www.pcguide.com”.

This exact same concept is used to organize MIB objects in SNMP. A single universal

hierarchy is used that contains all MIB objects. It is hierarchical in nature, and split into

levels from the most general to the most specific. Each object has a particular place in the

hierarchy. The names are formed by following the labels from the top of the tree down to the

place where the object is located, and separating them with “dots”. (SNMP doesn't reverse

the order of the labels the way DNS does, however. They are listed top-down from left to

right.)

There is another important difference between the MIB name hierarchy and the DNS one:

the MIB name hierarchy is even more universal than the one for DNS. The entire subtree of

all MIB objects is just one branch of the full, international object hierarchy maintained by

ISO and ITU. This object identification hierarchy is so general that it can contain a name for

every object or variable in use by any technology in the entire world. And possibly other

planets. Or solar systems. ☺

The reason for my jocularity will become apparent in a moment. Suffice to say, this object

tree is enormous. Each node in this tree is identified with both a label and an integer. The

labels are for descriptive purposes; object (or subtree) identifiers are formed by listing the

numbers in sequence from the top of the tree down to the node, separated by dots. (The

text labels can be used for names too but are not because they would get very long due to

how deep the tree structure is.)

Key Concept: SNMP MIB objects have two names. The first is a text object

descriptor, which provides a means of addressing the object in a way that is familiar

and easy for humans. The second is the object identifier, which consists of a

sequence of integers that specifies the location of the object in the global object hierarchy

maintained by the international standards bodies ISO and ITU.

Structure of the MIB Object Name Hierarchy

Let's explore how the MIB object tree is structured, and more importantly, how SNMP MIB

objects fit into it (you may find referring to Figure 273 useful as you proceed here.) The

tree’s root has no label, and has three children:

☯ ccitt(0): For ITU (formerly the CCITT) standards. (Also seen as itu(0)).

☯ iso(1): For ISO standards.

☯ joint-iso-ccitt(2): For joint standards. (Also seen as joint-iso-itu(2)).

Following the iso(1) node, we see the following at the next several levels:

☯ Within iso(1), the ISO has created a subtree for use by other organizations, called

org(3).

☯ Within org(3), there is a subtree for the United States Department of Defense, which as

you may recall was the originator of the Internet: dod(6).

☯ Within dod(6), there is a subtree called internet(1).

Everything we work with in SNMP is under this one very specific subtree: 1.3.6.1, which if

we used the text labels would be “iso.org.dod.internet”. Within this part of the name space,

there are six subtrees below:

☯ directory(1): Reserved for future use by ISO.

☯ mgmt(2): The primary subtree where MIB objects are located. This is “1.3.6.1.2”. It

contains a subtree called mib(1), which is 1.3.6.1.2.1. When MIB-II was created, a

subtree called mib-2(1) was created using the same number, 1.3.6.1.2.1.

☯ experimental(3): Contains objects used for standards under development. This is

“1.3.6.1.3”.

☯ private(4): Used for objects defined by private companies. This node, 1.3.6.1.4, has a

subtree called enterprise(1), which is 1.3.6.1.4.1.

☯ security(5): Reserved for security use.

☯ snmpV2(6): Defines objects used specifically for SNMP version 2.

Phew. So, what's the bottom line of all this? Well, basically all MIB module objects are

named within one of these two branches of the overall object tree:

☯ Regular MIB Objects: These are in the mib(1) subtree under mgmt(2): 1.3.6.1.2.1.

Figure 273: Global Object Name Hierarchy and SNMP MIB Hierarchies

This diagram shows the object name hierarchy defined by ISO and CCITT (ITU) to allow all types of objects to

be universally represented. The “path” within this larger tree to the tree branches relevant to SNMP can be

found by following the colored boxes. The two subtrees used for SNMP are shown in light blue. Each contains

its own substructure (some of which is illustrated by boxes in purple) defining thousands of different MIB

objects. The branch on the left side is used for generic MIB objects and the one on the right for private ones. A

separate hierarchy is also define for SNMP V2.

(root)

{}

ccitt (0)

...

standard(0)

iso(1)

{1}

joint-iso-ccitt(2)

registration-

authority(1)

membe r-

body(2)

identified-

organization(3)

{1 3}

...

sys(1)

dod(6)

{1 3 6}

......

internet(1)

{1 3 6 1}

directory(1) mgmt(2)

{1 3 6 1 2}

experimental(3)

private(4)

{1 3 6 1 4}

security(5) snm p V 2(6)

{1 3 6 1 6}

mib/mib-2(1)

{1 3 6 1 2 1}

enterprise(1)

{1 3 6 1 4 1}

......

if(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) cmot(9) trans(10) snm p(11)

cisco(9)

{1 3 6 1 4 1 9}

...

☯ Private MIB Objects: These are in the enterprise(1) subtree under private(4), which is

1.3.6.1.4.1. For example, within enterprise(1) there is an entry cisco(9) for Cisco

Systems. So all Cisco-specific MIB objects start with 1.3.6.1.4.1.9.

Clear as mud, right? Why didn't they just make a separate hierarchy where “mib” was at the

top instead of 6 levels deep? How dare you even suggest such a thing. Don't you under-

stand the importance of global standards? ☺

All facetiousness aside, this name hierarchy is a bit cumbersome to deal with (okay, more

than a bit) but it does allow us to keep MIB objects organized in a sensible way. Within the

1.3.6.1.2.1 subtree we find most of the regular MIB objects used in SNMP. Each subtree

within 1.3.6.1.2.1 corresponds to one of the regular SNMP object groups or a particular MIB

module.

Key Concept: All MIB objects have object identifiers that fit within two branches of

the global object hierarchy. Regular MIB objects (which are not vendor-specific) fit in

the mib(1) subtree under mgmt(2): 1.3.6.1.2.1. Private objects, which can be created

by a hardware vendor to assist in managing that vendor’s products, are in the enterprise(1)

subtree under private(4), which is 1.3.6.1.4.1

Recursive Definition of MIB Object Identifiers

An object is given a text object descriptor by putting its name at the start of the object as

shown in Table 208, but the definition of numeric object identifiers is, again, more complex.

It is done by defining only the number of the object within its particular subtree. This means

the object identifiers are defined recursively (one based on another) and are not explicitly

stated for each object. Syntactically precise, but makes it hard to see at a glance what the

number is for any particular object.

Consider again the example in Table 208. For this object, sysLocation is the object

descriptor, and “{ system 6 }” is the object identifier. This means it is object number 6 within

the node system, which is in turn defined as “{ mib-2 1 }”—it is the first node within the mib-

2 subtree. Since mib-2 is, as we said above, 1.3.6.1.2.1, this means system is 1.3.6.1.2.1.1

and sysLocation is 1.3.6.1.2.1.1.6.

TCP/IP MIB Modules and Object Groups

The Management Information Base (MIB) contains the collection of MIB objects that

describe the characteristics of a device using the Internet Standard Management

Framework (SNMP Framework). When SNMP was first created, there were not that many

objects in the MIB. Furthermore, they were mostly “generic” objects that applied fairly

universally to TCP/IP devices as a whole. In fact, most of the MIB objects were variables

related to the operation of TCP/IP protocols such as IP, TCP and ICMP.

For this reason, at first, a single document defined “the” Management Information Base

(MIB) for SNMP. The first of these documents was RFC 1066, part of the initial SNMPv1

specification. It was then revised in RFC 1156. In RFC 1158, a second version of the MIB,

MIB II, was defined, which was essentially the same but made a few changes.

The Organization of MIB Objects into Object Groups

The number of MIB objects defined in these standards was relatively small. However, there

were still several dozen of them, and it was recognized from the start that more would be

created in time. To help organize the objects in a logical way, they were arranged into object

groups. These groups serve the purpose of separating the objects and defining how they

should be given object identifiers in the overall object name hierarchy.

Each group has associated with it three important pieces of information:

☯ Group Name: A name that is used as a text label in the object identification tree we

saw in the previous topic. These objects are all located within the

“iso.org.dod.internet.mgmt.mib” subtree. So for example, the group system would be

“iso.org.dod.internet.mgmt.mib.system”.

☯ Group Number: A number corresponding to the group name used for making numeric

identifiers from the object name tree. For example, the group system has the number

1, and so the group's object identifier is 1.3.6.1.2.1.1. All objects in that group will be

under that tree; for example, sysUpTime is 1.3.6.1.2.1.1.3.

☯ Group Code: A text label that may be the same as the group name or may be an

abbreviation. It is used as a prefix in making object descriptors (the text names of

objects). For example, for the group system the code is sys, and so an object in this

group is sysUpTime.

Generic MIB Object Groups

Table 209 shows the eight generic SNMP groups defined in RFC 1158 along with their

codes, names and numbers.

Table 209: SNMP Generic MIB Object Groups (Page 1 of 2)

Group

Name

Group

Code

Group

Number

Full Group

Identifier

Description

system sys 1 1.3.6.1.2.1.1

General objects of relevance to all or most

devices. For example, a general description of the

device is an object in this group, as is the identifier

of the object. Later MIB versions greatly expanded

the number of variables in this group.

Interfaces if 2 1.3.6.1.2.1.2

Objects related to the IP interfaces between this

device and the internetwork; recall that a regular

host normally has one interface while a router has

two or more.

at (address

translation)

at 3 1.3.6.1.2.1.3

Objects used for IP address translation. (No

longer used.)

All of the groups in this table are fairly generic, and with the exception of the one about

EGP, apply to pretty much every TCP/IP system using SNMP. The first five groups and the

last one are “mandatory” for all systems; the others are used only by devices that use the

indicated protocols or functions. The mention of EGP, a routing protocol now considered

obsolete, shows the age of this list.

MIB Modules

What's most conspicuous about Table 209 are the groups that are not in it. There are no

groups for most of the other TCP/IP protocols, nor any for variables that might be needed

for specific hardware types. For example, most hosts will have a network card in them using

a layer two protocol like Ethernet or Token Ring; how does a manager check or control the

operation of this hardware? What about newer routing protocols like OSPF or BGP? How

about objects related to running the Domain Name System?

Updating the MIB document constantly would have been impractical. Instead, in SNMPv2,

the Management Information Base was changed from a single document to a group of

documents. The basic organization into groups of objects was retained, but instead of all

groups being in the same standard, they are divided into multiple standards. A method was

also defined for how to create MIB modules that describe new groups of objects specific to

a particular technology. A list of these modules is maintained by IANA, the organization that

maintains all of these sorts of numbers.

ip ip 4 1.3.6.1.2.1.4

Objects related to the IP layer of the device as a

whole (as opposed to interface-specific infor-

mation in the if group.)

icmp icmp 5 1.3.6.1.2.1.5

Objects related to the operation of the Internet

Control Message Protocol.

tcp tcp 6 1.3.6.1.2.1.6

Objects related to the operation of the Trans-

mission Control Protocol.

udp udp 7 1.3.6.1.2.1.7

Objects related to the operation of the User

Datagram Protocol.

egp egp 8 1.3.6.1.2.1.8

Objects related to the operation of the Exterior

Gateway Protocol.

cmot cmot 9 1.3.6.1.2.1.9

Objects related to running the CMIP protocol over

TCP (historical, not used.)

transmission trans 10 1.3.6.1.2.1.10

Objects related to the specific method of infor-

mation transmission used by each interface on the

system.

snmp snmp 11 1.3.6.1.2.1.11 Objects used to manage SNMP itself.

Table 209: SNMP Generic MIB Object Groups (Page 2 of 2)

Group

Name

Group

Code

Group

Number

Full Group

Identifier

Description

On The Web: The current list of SNMP MIB modules can be found here: http://

www.iana.org/assignments/smi-numbers

The use of MIB modules makes putting SNMP support into a device somewhat like “going

shopping”. The basic groups common to all devices are incorporated into each device, and

then other modules/groups are used as needed. Table 210 provides a brief selection of MIB

modules to give you an idea of what is out there, also showing the module's group number

(within the 1.3.6.1.2.1 name subtree):

There are of course, many, many more. The last three entries in the table above might

seem a bit confusing, since there are already groups for IP, TCP and UDP in the first table

above. The reason for these is that when the new modular architecture for MIB objects was

created in SNMPv2, the definition of objects for the individual protocols that was part of the

“one document” in SNMPv1 was separated out into individual MIB documents for consis-

tency, and to allow them to be updated independently. In fact, the “base” SNMPv2 and

SNMPv3 MIB documents now only define objects in the system and snmp groups.

Table 210: Some Common SNMP MIB Modules

MIB Module

Name

Group

Number

Description

ospf 14 Objects related to the Open Shortest Path First protocol.

bgp 15 Objects related to the Border Gateway Protocol.

rmon 16

Objects used as part of Remote Network Monitoring (RMON),

which we'll examine later in this chapter.

snmpDot3

RptrMgt

22 Objects related to IEEE 802.3 (Ethernet) repeaters.

rip-2 23

Objects used as part of version 2 of the Routing Information

Protocol.

snmpDot3

MauMgt

26 Objects related to IEEE 802.3 (Ethernet) medium attachment units.

etherMIB 35 Ethernet-like generic objects.

mipMIB 44 Mobile IP objects.

ipMIB 48 Internet Protocol objects for SNMPv2.

tcpMIB 49 Transmission Control Protocol objects for SNMPv2.

udpMIB 50 User Datagram Protocol objects for SNMPv2.

Key Concept: MIB objects created early in SNMP’s history were organized into MIB

object groups that reside within mib(1) subtree, starting with identifier code

1.3.6.1.2.1. As the popularity of TCP/IP grew, it became impractical to centrally-

define all MIB objects, so sets of objects particular to different hardware devices are now

specified in MIB modules.

MIB Module Format

The format for MIB modules is described in the Structure of Management Information

standard, version 2 (SMIv2). The document specifies how modules are to be defined in a

way very similar to how objects themselves are defined, by listing a set of characteristics

that must be included in each module description. The module fields are:

☯ Module Name: The name of the module. Remember that modules are really objects,

syntactically, so like regular objects they have a textual object descriptor (like tcpMIB)

and an object identifier (in the case of tcpMIB, the number 50).

☯ Last Updated: The date and time that the module was last revised.

☯ Organization: The name of the organization that is managing the development of the

module.

☯ Contact Information: The name, address, telephone number and e-mail address of

the “point person” for this module.

☯ Description: A description of the module.

☯ Revision and Revision Description: One Revision entry is placed for each revision

of the module to show its history. Each entry has a description associated with it.

After the definition of the module itself, the objects in the module are described. For an

example, see RFC 2012, which defines the SNMPv2 TCP MIB we've been discussing in

this example.

TCP/IP Simple Network Management Protocol (SNMP) Protocol

The overall network management solution for TCP/IP networks is the Internet Standard

Management Framework. In the last two subsections we have taken a look at the

framework as a whole, and also discussed the two components that define the

management information transmitted between TCP/IP devices to accomplish network

management. The third major part of the SNMP Framework is the actual Simple Network

Management Protocol, SNMP, which is responsible for moving management information

between devices.

In this section, I describe the concepts and operation of the actual SNMP protocol. I begin

with a brief overview and history of the protocol, discussing it in general terms. I then have

two subsections that describe SNMP's operation in detail. The first covers the different

operations performed by the protocol and how they work. The second discusses protocol

messaging and message formats.

Background Information: Please be sure that you have a solid understanding of

SNMP Management Information Bases (MIBs) and MIB objects before proceeding

in this section.

SNMP Protocol Overview, History and General Concepts

I have described the TCP/IP Internet Standard Management Framework (SNMP

Framework) as being information-oriented. A specific decision was made in the design of

the SNMP Framework to decouple the management information conveyed between SNMP

agents and SNMP managers from the protocol used to carry that information. This provides

numerous benefits to the technology as a whole, chief among them flexibility and

modularity.

In this model, the operation of the management protocol is not defined in terms of specific

commands made to check the status of a device or change how it operates. Instead, the

protocol is defined in terms of management information variables called objects, and a

communication protocol that allows these objects to be either examined or changed by a

network administrator. I describe this concept thoroughly in the topic that overviews the

SNMP Management Information Base (MIB) and the Structure of Management Information

(SMI).

The MIB and SMI spell out the rules for how MIB objects are created and described. These

MIB objects describe the types of information that can be read from the device or written to

the device. The last piece of the puzzle is the actual protocol that is responsible for these

“read” and “write” operations. This is the Simple Network Management Protocol itself, which

I give the somewhat redundant name SNMP Protocol to differentiate it from the SNMP

Framework.

The result of the separation of the protocol from the management information it carries is

that the protocol itself becomes significantly reduced in complexity. Instead of the SNMP

Protocol having to define dozens or even hundreds of operations that specify particular

network management functions, it only has to deal with the transmission of MIB object infor-

mation between SNMP agents and managers. The SNMP Protocol does not itself pay

attention to what is in these objects; it is merely concerned with moving them around. In

some ways, the SNMP Protocol is the only really simple part of SNMP!

Early Development of SNMPv1

The history of the SNMP Protocol goes back to the predecessor of the SNMP Framework,

the Simple Gateway Monitoring Protocol (SGMP), which was defined in RFC 1028 in 1987.

SGMP was designed as an interim solution for network management while larger issues

were being explored as I explained in the overview of the SNMP Framework. However, this

standard is where many of the basic design concepts underlying the modern SNMP

Protocol can be found.

The SGMP standard specified the basic design model used in SNMP, by describing the

SGMP protocol in terms of only retrievals of, or alterations to, variables stored on an

Internet gateway (router). The standard also outlines the small number of protocol opera-

tions that are still the basis for SNMP's operation today.