An Example MIB2

Let us now consider an excerpt from MIB-2. For brevity, portions of the definition are omitted. The symbol [...] is used to indicate where information is omitted within the definition excerpts. We start by taking a look at the "header" of the MIB module.

RFC1213-MIB DEFINITIONS ::= BEGIN

This definition establishes mib-2 as a new node underneath a supernode called mgmt inside the Internet object identifier tree. (mgmt is imported from another standard; it identifies the subnode that is reserved for management information. Its complete OID is 1.3.6.1.2.) mib-2 is the human-readable form of the name; for machine-to-machine communication purposes, the equivalent numeric object identifier, 1, is used.

-- groups in MIB-II

system

OBJECT

IDENTIFIER :

:= {

mib-

-2

1

}

interfaces

OBJECT

IDENTIFIER :

:= {

mib-

-2

2

}

at

OBJECT

IDENTIFIER :

:= {

mib-

-2

3

}

ip

OBJECT

IDENTIFIER :

:= {

mib-

-2

4

}

icmp

OBJECT

IDENTIFIER :

:= {

mib-

-2

5

}

tcp

OBJECT

IDENTIFIER :

:= {

mib-

2

6

}

udp

OBJECT

IDENTIFIER :

:= {

mib-

2

7

}

egp

OBJECT

IDENTIFIER :

:= {

mib-

2

8

}

What gets defined here are internal nodes that are used for structuring purposes. Each of those nodes will contain a submodule of the MIB module, also called a group. The groups are assigned numeral identifiers 1 through 8 underneath the mib-2 node. Figure 6-13 depicts another excerpt from the object identifier tree defined by MIB-2, reflecting the remainder of the excerpt of MIB-2 that is presented here.

Figure 6-13 MIB-2 Naming Structure

Figure 6-13 MIB-2 Naming Structure

We now dive into the definition of one of the submodules, the system group. Note that the definition of MIB modules can be annotated with comments, which are lines prefixed with two dashes (--).

-- the System group

-- Implementation of the System group is mandatory for all

-- systems. If an agent is not configured to have a value

-- for any of these variables, a string of length 0 is

sysDescr OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION

"A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters." ::= { system 1 }

sysUpTime OBJECT-TYPE

SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION

"The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 }

sysContact OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION

"The textual identification of the contact person for this managed node, together with information on how to contact this person." ::= { system 4 }

The system group contains a number of scalars—object types that will be instantiated exactly once. The definition of an object type consists of several elements:

■ "Syntax" essentially defines the data type. sysDescr and sysContact are strings with a maximum length of 255 characters; sysUpTime is of a type TimeTicks. TimeTicks is a textual convention that is defined in an imported specification; it really refers to an unsigned 32-bit integer that represents an elapsed period of time in hundredths of a second, as reiterated in the description.

■ "Access" specifies whether the object is a parameter that can be set by a manager (read-write) or whether it can only be read, such as when the object contains state information. In the example here, sysUpTime is read-only—the agent provides its value as it reflects state information. sysContact, on the other hand, is read-write—its value is provided by a management application to facilitate administration of the device.

■ "Status" refers to the definition lifecycle. In the example, the status of every object is mandatory, meaning that every implementation of the MIB module must include it. The definition of the status is one of the aspects that has actually changed between SMI and SMIv2. In SMIv2, because of the introduction of module compliance statements, the distinction between object types whose implementation is mandatory versus those whose implementation is optional is no longer needed; both have been replaced by a new status, current. In general, every object type has a status of current. However, later revisions of MIB module may deprecate an object type. This means that new implementations do not have to support the object type but that it might be retained in existing implementations for backward compatibility reasons. In that case, the status would be deprecated. Finally, object types may also have a status of obsolete if they are no longer to be supported. Note that after it is defined, an object type never goes away even if it is obsoleted—this prevents accidental reuse of the same identifiers for another purpose because that reuse might lead to unintended confusion.

■ "Description" contains an explanation of the intended purpose of the object type. In addition, it can contain specification of any behavioral aspects that cannot be captured otherwise. In that sense, a description is more than merely a comment; it can contain a specification of aspects that need to be implemented and complied with.

■ Finally, each object type is assigned an object identifier, relative to a containing node.

We now turn our attention to another submodule, the TCP group. It contains definitions of management information for the TCP protocol. Among other things, it contains a definition of a table, as follows:

-- the TCP Connection table

-- The TCP connection table contains information about this -- entity's existing TCP connections.

tcpConnTable OBJECT-TYPE

SYNTAX SEQUENCE OF TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"A table containing TCP connection-specific information." ::= { tcp 13 }

tcpConnTable contains the definition of the table. It looks similar to the definition of scalar object types, with two exceptions:

■ Its syntax does not designate a simple data type, but a SEQUENCE OF objects of another type. Those objects are the table entries—the rows of the table.

■ Its access clause indicates that it is not accessible—it can be neither read nor written to, so for management purposes, it carries no information on its own. It is the topmost container object for the columnar objects that make up the actual management information contained in this table.

tcpConnEntry OBJECT-TYPE SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"Information about a particular current TCP connection. An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state."

INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { tcpConnTable 1 }

TcpConnEntry is the definition of the rows of the table. Its containing node is tcpConnTable. As with tcpConnTable, it is not accessible—it is a conceptual object. The accessible objects are the individual elements of the row—that is, the columnar objects. Two aspects make the definition of a table row unique:

■ The index clause is present only with object types that define a table entry. In database parlance, the index clause specifies the primary key of the table. It designates the columnar objects that are used to uniquely identify a row in the table. In this case, a row in the TCP connection table is identified by the combination of the local TCP connection address and port, and the remote TCP connection address and port.

■ The syntax clause does not designate a simple data type. It refers to a data type of

TcpConnEntry that is specified separately and whose definition you will see in a moment. TcpConnEntry is a data type of type Sequence. A sequence essentially corresponds to the programming language of a struct. It references as elements the individual columnar objects that comprise a row in the table. The syntax of TcpConnEntry is defined as follows, right after the TcpConnEntry data type (do not confuse the data type and its syntax):

TcpConnEntry ::= SEQUENCE {

tcpConnState INTEGER, tcpConnLocalAddress

IpAddress, tcpConnLocalPort

INTEGER (0..65535), tcpConnRemAddress

IpAddress, tcpConnRemPort

INTEGER (0..65535)

Note that TcpConnEntry contains a definition of all columns of the table, including the columns that are collectively used as the index and any additional columns—in this case, tcpConnState. Each of the elements of the sequence designates its own object type that will be instantiated by the columnar objects that populate the respective column in the table. The only part that is now missing is the actual object type definitions, to resolve the elements identified in the TcpConnEntry sequence. Here are their definitions:

tcpConnState OBJECT-TYPE SYNTAX INTEGER {

closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(ll), deleteTCB(12)

ACCESS read-write STATUS mandatory DESCRIPTION

"The state of this TCP connection.

The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a 'badValue' response if a management station attempts to set this object to any other value.

If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection.

As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note however that RST segments are not sent reliably)." ::= { tcpConnEntry 1 }

tcpConnState is the first of the object types that comprise the table. It is worth noting that the definition of columnar object types does not differ from that of scalar object types. You cannot tell from the definition which is which. The one aspect that makes it a columnar object type is that the containing node is a table row (tcpConnEntry), and the name of the object type is referenced in the sequence that is defined as part of the syntax of the table row.

tcpConnState is also noteworthy as an example of an object type in which the description cause contains not only an explanation, but a specification of certain other aspects that would otherwise not be captured—in this case, restrictions with respect to the values that can be set, along with a description of the side effects that setting of this object will cause.

tcpConnLocalAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION

"The local IP address for this TCP connection. In the case of a connection in the listen state which is willing to accept connections for any IP interface associated with the node, the value 0.0.0.0 is used." ::= { tcpConnEntry 2 }

tcpConnLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION

"The local port number for this TCP connection." ::= { tcpConnEntry 3 }

tcpConnRemAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION

"The remote IP address for this TCP connection." ::= { tcpConnEntry 4 }

tcpConnRemPort OBJECT-TYPE

SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION

"The remote port number for this TCP connection." ::= { tcpConnEntry 5 }

The example concludes with the definition of the remaining object types that are contained underneath a tcpConnEntry. Those object types are unremarkable in every way. The fact that they also serve as an index in the table is transparent in the definition of the object types themselves. Because they collectively serve as an index that needs to uniquely identify a table entry, the combination of the values tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, and tcpConnRemPort must be unique as well—that is, it cannot occur more than once in the same MIB. This constraint cannot be inferred from the object type definitions themselves—only from the fact that they appear in the index clause of tcpConnEntry.

Was this article helpful?

0 0

Post a comment