UNIX System Administration Handbook - Evi Nemeth [379]
A major advantage of management-by-protocol is that it promotes all kinds of network hardware onto a level playing field. UNIX systems are all basically similar, but routers, switches, and other low-level components are not. With SNMP, they all speak a common language and can be probed, reset, and configured from a central location. It’s nice to have one consistent interface to all the network’s hardware.
20.7 SNMP: THE 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 organization
SNMP data is arranged in a standardized hierarchy. This enforced organization 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
a. 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