SNMP: Simple network management protocol
When SNMP first became widely used in the early 1990s, it started a mini gold rush. Hundreds of companies have come out with SNMP management packages. Also, many hardware and software vendors ship an SNMP agent as part of their product.
Before we dive into the gritty details of SNMP, we should note that the terminology associated with it is some of the most wretched technobabble to be found in the UNIX arena. The standard names for SNMP concepts and objects will actively lead you away from an understanding of what's going on. The people responsible for this state of affairs should have their keyboards smashed.
SNMP organisation
SNMP data is arranged in a standardised hierarchy. This enforced organisation allows the data space to remain both universal and extensible, at least in theory. Large portions are set aside for future expansion, and vendor-specific additions are localized to prevent conflicts. The naming hierarchy is made up of -Management Information Bases" (MIBs), structured text files that describe the data accessible via SNMP. MIBs contain descriptions of specific data variables, which are referred to with names known as object identifiers or OIDs.
Translated into English, this means that SNMP defines a hierarchical namespace of variables whose values are tied to -interesting" parameters of the system.
The basic data types that an SNMP variable can contain are integer, string, and null. These can be combined into sequences of the basic types, and a sequence can be instantiated repeatedly to form a table. Most implementations support a variety of other data types as well.
The SNMP hierarchy is very much like a filesystem. However, a dot is used as the separator character, and each node is given a number rather than a name. By convention, nodes are also given text names for ease of reference, but this naming is really just a high-level convenience and not a feature of the hierarchy (it is similar in principle to the mapping of hostnames to IP addresses). For example, the OID that refers to the uptime of the system is 1.3.6.1.2.1.1.3. This OID is also known by the human readable name
iso.org.dod.internet.mgmt.mib-2.system.sysUpTime
The top levels of the SNMP hierarchy are political artifacts and generally do not contain useful data. In fact, useful data can currently be found only beneath the OID iso.org.dod.internet.mgmt (numerically, 1.3.6.1.2).
The basic SNMP MIB for TCP/IP (MIB-I) defines access to common management data: information about the system, its interfaces, address translation, and protocol operations (IP, ICMP, TCP, UDP, and others). A later and more complete reworking of this MIB (called MIB-II) is defined in RFC1213. Most vendors that provide an SNMP server support MIB-II. Table 20.1 presents a sampling of nodes from the MIB-II namespace.
Table 20.1 Selected OIDs from MIB-II
| OID | Type | Contents |
|---|---|---|
| system.sysDescr | string | System info: vendor, model, OS type, etc. |
| system.sysLocation | string | Physical location of the machine |
| system.sysContact | string | Contact info for the machine's owner |
| system.sysName | string | System name, usually the full DNS name |
| interfaces.ifNumber | int | Number of network interfaces present |
| interfaces.ifTable | table | Table of infobits about each interface |
| ip.ipForwarding | int | 1 if system is a gateway, otherwise 2 |
| ip.ipAddrTable | table | Table of IP addressing data (masks, etc.) |
| ip.ipRouteTable | table | The system's routing table |
| icmp.icmpInRedirects | int | Number of ICMP redirects received |
| icmp.icmpInEchos | int | Number of pings received |
| tcp.tcpConnTable | table | Table of current TCP connections |
| udp.udpTable | table | Table of UDP sockets with servers listening |
(Note: OID is relative to iso.org.dod.internet.mgmt.mib-2.)
In addition to the basic MIB, there are MIBs for various kinds of hardware interfaces and protocols. There are MIBs for individual vendors and MIBs for particular hardware products. A MIB for you, a MIB for me, catch that MIB behind the tree.
A MIB is only a convention about the naming of management data. It must be backed up with agent-side code that maps between the SNMP namespace and the device's actual state to be useful. Code for the basic MIB (now MIB-II) comes with most UNIX SNMP agents. Some agents are extensible to include supplemental MIBs, and some are not.
SNMP protocol operations
There are only four basic SNMP operations: get, get-next, set, and trap.
Get and set are the basic operations for reading and writing data to a node identified by a specific OID. Get-next is used to step through a MIB hierarchy, as well as to read the contents of tables.
A trap is an unsolicited, asynchronous notification from server (agent) to client (manager) that reports the occurrence of an interesting event or condition. Several standard traps are defined, including -I've just come up" notifications, traps that report the failure or recovery of a network link, and traps for various routing and authentication problems. Many other not-so-standard traps are in common use, including some that simply watch the values of other SNMP variables and fire off a message when a specified range is exceeded. The mechanism by which the destinations of trap messages are specified depends on the implementation of the agent.
Since SNMP messages can potentially modify configuration information, some security mechanism is needed. The simplest version of SNMP security is based on the concept of an SNMP -community name," which is really just a horribly obfuscated way of saying -password." There's usually one community name for read-only access and another that allows writing.
Version 3 of the SNMP standard introduced access control methods with higher security. Although support for these schemes is still somewhat limited in production network hardware, it is reasonable to expect this situation to change soon.
RMON: Remote monitoring MIB
The RMON MIB permits the collection of generic network performance data (that is, data not tied to any one particular device). Network sniffers or -probes" can be deployed around the network to gather information about utilisation and performance. Once a useful amount of data has been collected, statistics and interesting information about the data can be shipped back to a central management station for analysis and presentation. Many probes have a packet capture buffer and can provide a sort of remote tcpdump facility.
RMON is defined in RFC1757, which became a draft standard in 1995. The MIB is broken up into nine -RMON groups." Each group contains a different set of network statistics. If you have a large network with many WAN connections, you should consider buying probes to reduce the SNMP traffic across your WAN links. Once you have access to statistical summaries from the RMON probes, there's usually no need to gather raw data remotely. Many switches and routers support RMON and will store at least some network statistics.
4%
2%
