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

Lecture 17: Network Management #2

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.
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: these contain information about the performance of these transport-layer protocols.
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

A great deal of network managment relates to the IP subsystem. Some IP scalar objects are as follows:

ipForwarding: this node is acting as an IP gateway (router). Otherwise it is a host.
ipDefaultTTL: default TTL for datagrams
ipInReceives: total datagrams received from the underlying MAC layer.
ipForwDatagrams: number forwarded
ipInDiscards: number of datagrams discarded 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.
get-next: retrieve via MIB traversal, management information.
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.

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

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".

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 adding a zero 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
Thus to retrieve the instance information specified above, we could use:
get (system.sysDescr.0)
or
get (1.3.6.1.2.1.1.1.0)

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 defines:
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)

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 Message Example

The following^[2] 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

^[1] 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.
nocol: 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.

^[3] RFCs 1441 to 1452!!

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

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