Subjects -> Computer Networks -> Lectures -> Lecture #23

Lecture 23: Network Management #3

The Internet Standard MIB - top level

The following are the groups defined in MIB II^[1]:

system: describes the managed node, its "uptime", its name and the name of the person responsible for its management, plus some other info. The variable system.sysDescr is especially interesting.
interfaces: contains information on the interfaces installed on the node.
address translation (at): contains address resolution table of the managed node: basically the same information as given by the arp command on UNIX. The at group is depreciated in MIB II: this info is moved into each network protocol group.
IP: contains a great deal of information on the IP sub-system. See next slide.
ICMP: contains mainly counters, giving the number of each type of ICMP datagrams sent and received.
TCP & UDP groups: Contain information about the performance of these transport-layer protocols. These are (obviously) not very interesting for a router.
EGP, Transmission Group, SNMP group: see today's tutorial.

^[1] MIB II (rfc1213) replaced the original (rfc 1155/6) MIB specification in 1991

The IP MIB Group

Most of the interesting network managment information relates to the IP subsystem. Some IP scalar objects are as follows:

ipForwarding: If this BOOLEAN variable is TRUE, this node is acting as an IP gateway (router). Otherwise it is a host.
ipDefaultTTL: Default TTL for datagrams originating from this node -- typically 60.
ipInReceives: Total number of datagrams received from the underlying MAC (usually Ethernet) layer by the IP subsystem.
ipForwDatagrams: Total number of datagrams forwarded (ie, routed) by this router.
ipInDiscards: Total number of datagrams discarded (ie, dropped) due to resource limitations
...plus many more

There are also several tables associated with the IP subsystem:

ipAddrTable: maintains information about each of the IP addresses on a node: netmask, broadcast, etc
ipRoutingTable: keeps track of routes associated with the node. Each route is an ipRouteEntry type.
IP Address translation table: (in MIB-II) contains entries for MAC-to-IP mapping address mapping for each interface.

The SNMP Protocol

SNMP version 1 only defines four operations:

get: retrieve specific management information from a managed node^[2]
get-next: retrieve via MIB traversal, management information. See later.
set: used to manipulate management information.
trap: used to report extraordinary events.

It also defines the reply operation:

get-response: contains the information requested from the managed node.

An SNMP message contains, along with data describing the SNMP commands or responses, a community name identifying that the sender is a member of an identified community, or group of managed nodes. This allows a trivial level of authentication, since the community name almost always defaults to "public".

^[2] The SNMP get request, despite having a superficially similar name to the HTTP GET request, is utterly and completely unrelated to it. SNMP requests and responses are ASN.1 objects, encoded using BER, see below. They have no similarity to the HTTP "plain text" protocol.

Instance Specification

The MIB specifies the structure of managed information. A particular instance of a piece of information in a managed node (that is, the actual value of a specified variable) is specified by appending a zero sub-identifier to the OBJECT IDENTIFIER, thus:

If the particular information is not a column in a table (ie, it is a scalar), then the OBJECT IDENTIFER is given a suffix of zero, thus:
system.sysDescr.0
or
.1.3.6.1.2.1.1.1.0
The meaning of this "instance information" is that it is the value of the OID "system.sysDescr" -- in other words, the actual octet (byte) string describing the managed node. To retrieve the instance information specified here, we could use (imaginary syntax :-):
get system.sysDescr.0 
or
get 1.3.6.1.2.1.1.1.0 
Note that this syntax is simply for illustration purposes: you can't (for example) type these lines to a command interpreter.

Instance Specification -- Tables And Lists

If the information is a column in a table (or list) of related information, a suffix is added which uniquely identifies the desired instance.

For example, in the "{ interfaces }" group, the first data type is a scalar, thus:
ifNumber ::= { interfaces 1 }
This is the number of interfaces a device has, regardless of their status. The MIB then goes on to define:
ifTable ::= SEQUENCE OF ifEntry
and
ifEntry ::= SEQUENCE {
    ifIndex ::= INTEGER,
    ...
    ifOperStatus::= INTEGER,
    ...etc }
As an example, to retrieve information about (for example) the operational status of interface number 3, where multiple interfaces are in use, we could use:
get interfaces.ifTable.ifEntry.ifOperStatus.3
This would return one of three integer values: 1 for up, 2 for down and 3 for testing, see MIB definition.

The Powerful Get-Next Operation

The "powerful get-next" is used to move from one object instance to the next in a managed node. For example:

get-next system.sysDescr.0

should return the lexicographically next instance in the MIB, thus:

sysObjectID.0

The operand of get-next need not be an instance specifier: it can be any OBJECT IDENTIFIER. Hence the call:

get-next system.sysDescr

returns the next instance, thus:

sysDescr.0

get-next can also take multiple operands, thus it is possible to use it to obtain multiple columns within a single row of a table of information in a single operation, eg:

get-next ipRouteDest, ipRouteIfindex

This is considered to be very useful, hence the terminology powerful get-next

SNMP Message (PDU) Encoding

SNMP not only describes its data structures in terms of ASN.1, it also uses to define its message format (ie, its PDUs, or "packets"):

SNMP-Message ::= SEQUENCE {
    version INTEGER { version-1 (0)},
    community OCTET STRING,
    data ANY
}

The data field of the SNMP message contains the SNMP PDU. For example, an SNMP get-request PDU is defined as follows:

GetRequest-PDU ::= [0] IMPLICIT SEQUENCE {
    request-id RequestID,
        -- 4 byte integer to match requests and responses
    error-status ErrorStatus,
    error-index  ErrorIndex,
        -- both single byte integers, = 0 in requests, error status in responses
    variable-bindings VarBindList
        -- list of desired object identifiers as name/value pairs

SNMP (normally) uses the low-overhead, connectionless UDP protocol for transmission of requests and responses.

SNMP Message Example

The following^[3] gives the encoded octets in a get-request message for the data item sysDescr (1.3.6.1.2.1.1.1)

   30      29      02     01    00
SEQUENCE len=41 INTEGER len=1 vers=0

   04     06   70  75  62  6C  69  63
string  len=6   p   u   b   l   i   c

A0       1C      02     04   05 AE 56 02
getReq len=28 INTEGER len=4   -req ID-

   02     01    00      02     01   00
INTEGER len=1 status INTEGER len=1 index

   30      0E      30      0C   06   08
SEQUENCE len=14 SEQUENCE len=12 OID len=8

 2B  06  01  02  01  01  01  00
1.3 . 6 . 1 . 2 . 1 . 1 . 1 . 0

 05    00
NULL len=0

^[3] Thanks to Comer for this example.

SNMP Implementations

The CMU SNMPlib software is a set of Unix command-line tools which implement each of the four SNMP operations, plus some other useful functions. Examples of use of some of these tools include:

snmpget 149.144.21.254 public system.sysDescr.0
snmpget 149.144.21.254 public interfaces.ifTable.ifEntry.ifOperStatus.3
snmpgetnext 149.144.21.254 public system

More complex software systems permit regular monitoring of many variables. These have been developed into a variety of Network Operations Console software packages. Some examples include:

tkined: a free, graphically-oriented software system for use in Unix/X windows environments. Allows SNMP monitoring as well as Unix "rstat" and ICMP. Installed on the departmental SGI systems for your enjoyment.
SNIPS: a terminal-oriented tool with some superficial similarities to tkined.
SunNet Manager, HP OpenView, IBM NetView, etc: commercial software implementations of SNMP, often with many proprietory enhancements.

SNMPv2

Despite some weird political manoeuverings in 1992 and thereabouts, SNMPv2^[3] has been proposed as a replacement for SNMP. The SNMPv2 protocol adds:

Considerably extended communication model (parties, MIB views, etc)
Security protocols: MD5 for authentication, time stamping of messages, and even optional DES encryption of all messages.
A new Structure of Management Information (ie, a whole new MIB), located at { internet SNMPv2(6) }
Communications between manager stations
get-bulk protocol operation - retrieves a large amount of management information (like, a whole MIB!) in a single transaction, minimising network overhead.
Backward compatability with SNMP

Nevertheless, SNMPv2 has been widely criticised for its higher complexity, overhead, incompability with older MIBs, etc, etc.

The tutorial for this lecture is Tutorial #23.
La Trobe Uni Logo

[Previous Lecture] [Lecture Index] [Next Lecture]