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:
- 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.
- Downward compatability with SNMP
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