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. This is depreciatedM 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. 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 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[2] has been proposed as a replacement for SNMP. The SNMPv2 protocol adds: Nevertheless, SNMPv2 has been widely criticised for its higher complexity, overhead, incompability with older MIBs, etc, etc.

[2] rfc's 1441 to 1452!!

This lecture is also available in PostScript format. The tutorial for this lecture is Tutorial #16.
Phil Scott