A large portion of a system administrator's time can be consumed by network-related tasks. Installing and configuring a network can be daunting, especially if you're starting from scratch. But monitoring and managing the network on an ongoing basis can be just as daunting, especially for very large networks. Fortunately, network monitoring and management tools can make this job easier.
A large portion of a system administrator’s time can be consumed by network-related tasks. Installing and configuring a network can be daunting, especially if you’re starting from scratch. But monitoring and managing the network on an ongoing basis can be just as daunting, especially for very large networks. Fortunately, network monitoring and management tools can make this job easier.
Let’s take a look at managing the devices that use the Simple Network Management Protocol (SNMP), the network service that underlies many network management programs. We’ll start off this month with a brief look at SNMP’s fundamental concepts and data entities. Next month we’ll configure it on a Linux system and discuss security issues that must be resolved when using SNMP.
For a more in-depth information on the SNMP protocol, see “Network Device Interrogation” in the November 2001 issue (http://www.linux-mag.com/2001-11/snmp_01.html). A good book on SNMP is Essential SNMP by Douglas Maurot and Kevin Schmidt (O’Reilly & Associates, 2000).
SNMP Concepts and Constructs
SNMP was designed to be a consistent interface to gather data and set parameters for various network devices, which include switches and routers, network hosts (computers) running almost any operating system, printers, and more. It’s reasonably successful at doing this once it is configured and running in the right places. The hard part is getting used to its somewhat counterintuitive terminology.
SNMP has been around since the late 1980s, and there are many versions of it (including several flavors of version 2). The versions most often implemented are version 1 and version 2c. There is also a version 3 in development as of this writing. We’ll be looking at version 2c, but will address version-specific issues as they come up.
|Figure One: SNMP Manager and Agents|
Figure One shows a basic SNMP setup. In this setup, one computer is called the Network Management Station (NMS). It’s job is to collect and act on information from the various devices being monitored and/or controlled. In our example this includes two computers, a router, a network printer, and an environmental monitoring device.
In the simplest cases, the NMS periodically polls the devices it’s managing, sending queries for their current status. The monitored devices respond by transmitting the requested data and can also send traps (also known as notifications in SNMP version 2). A trap is an unsolicited message to the NMS, generated when a monitored parameter reaches unacceptable levels. For example, an environmental monitoring device may send a trap when the temperature or humidity are too low or too high.
Traps are useful because they provide an asynchronous way for a device to signal that something unexpected has occurred. If an important component such as a router has a problem, you wouldn’t want to wait until the next time the device was polled to find out that there is a problem.
In SNMP, the term “manager” refers both to the monitoring software running on the NMS and the actual device running the software. Similarly, the term “agent” refers to the software used by the monitored devices to generate and transmit their status data as well as the device being monitored.
SNMP is a client-server protocol, but its use of “client” and “server” are reversed from typical usage: the local manager functions as the client and the remote agents function as servers. SNMP uses terminology in the same way the X Window System does: X clients run on a local host and talk to server applications on remote hosts. SNMP normally communicates on TCP and UDP ports 161, and traps use TCP and UDP ports 162, but some vendors use different ports for traps (e.g., Cisco uses TCP and UDP ports 1993).
Climbing the MIB Tree
For an SNMP manager to communicate with an agent, it must know what various data values a particular agent is monitoring. These data values and the contents associated with them are defined in Management Information Bases (MIBs). A MIB is a collection of data values and their definitions arranged in a tree-based hierarchy.
The MIB is not a database; it doesn’t actually hold any data itself. It’s simply a definition of the data values that can be monitored or modified. These data definitions and naming conventions are used by the SNMP agent software, which collects the actual values for these definitions from the device and either makes them available for the NMS to query, or sends a trap if conditions warrant.
MIBs are often stored as text files for use by SNMP managers. MIBs can be standard (and are implemented by every agent), or proprietary, defining data values that are specific to a manufacturer and/or class of device.
|Figure Two: General SNMP MIB Hierarchy|
Let’s look at a sample from an actual MIB. Figure Two contains a subset of the overall SNMP hierarchy. The red items are leaf nodes (also known as “data nodes”), which are the only nodes in the tree that contain data definitions and values. The three data nodes (left to right) correspond to the system location description, the current number of processes on the system, and the system load average. The names of the data nodes are case-sensitive.
To access each leaf node, you’d normally start at the top (root) of the tree and work downwards, using a period to separate each data node. Thus, the data node that contains the system location description can be accessed with the string iso.org.dod.internet.mgmt.mib-2.system. sysLocation. This data node is defined to hold a character string, and a possible value for this data node might be “Dabney Building, 2nd Floor.”
The tree structure groups data values that are related to each other. For example, although it’s not illustrated here, there are various items below the system data node that relate to overall system (or device), including its name, physical location (sysLocation), and primary contact person.
It’s important to note that some data nodes are considered “static,” such as sysLocation. Once set, static data nodes are unlikely to change and would probably only be queried when the manager software starts up. Other data nodes are considered “dynamic,” such as the load averages stored in the laLoad data node. The agent software will frequently update the data node and the manager software will query the agent for this value frequently as well.
Not every data node represented in a MIB will be relevant to every device. The agent software on the device can choose what data nodes are important to it.
The top four levels of the tree (iso.org.dod.internet) only exist for historical reasons, and most data nodes are defined to be within the mgmt.mib-2 and private. enterprises subtrees.
Although only two of mgmt.mib-2‘s direct children are shown in Figure Two (system, which holds general information about the device, and host, which holds data related to computers), other important children of mib-2 are interfaces (which are defined to hold information about the device’s network interfaces), ip, tcp and udp (protocol-specific data), and snmp (SNMP traffic data).
The private.enterprises section of the MIB tree contains vendor-specific data definitions. Every vendor is assigned a unique identifier under this node; in Figure Two, the nodes for the University of California-Davis and Cisco Systems are shown. For a list of all assigned numbers (and their corresponding names), see ftp://ftp.isi.edu/in-notes/ iana/assignments/enterprise-numbers. You can request a number for your organization from the Internet Assigned Numbers Authority (http://www.iana.org/cgi-bin/enterprise.pl).
The ucdavis subtree is important for Linux systems because the open source SNMP package generally used on Linux, Net-SNMP, has been developed by UC-Davis for a long time, and is the subtree that contains the definitions that specifically applies to Linux SNMP agents.
Each data node within the MIB hierarchy has both a name and a number associated with it and can be referred to by either. The numbers for each item are shown in parentheses in Figure Two. For example, iso.org.dod.internet.mgmt.mib-2.system.sysLocation can also be referred to as 18.104.22.168.22.214.171.124. Similarly, the laLoad data can be accessed as iso.org.dod.internet. private.enterprises.ucdavis.laTable.laEntry.laLoad or as 126.96.36.199.4.1.2021.10.1.3. Each of these name types is known generically as an OID (object ID). Sometimes, only the name of the final data node (sysLocation or laLoad) is needed to refer to a data node, but sometimes the full “path” of the OID must be specified.
The SNMP Community
Access to SNMP data is controlled by passwords that are called “community” names or strings. There are generally separate community names for the agent’s read-only and read-write modes, as well as an additional name used for traps. Each SNMP agent knows its name (or password) for each mode, and will not answer queries that specify anything else. Community names can be up to 32 characters long and should be chosen using the same security considerations as root passwords (not easily guessable or crackable). We’ll discuss security issues in more detail next month.
Unfortunately, many devices are shipped with SNMP enabled, and have the read-only community name set to “public” and sometimes the read-write community name set to “private”. It’s important that you change these values (or at least disable SNMP for the device) before the device is added to the network. Otherwise, it is vulnerable to attack by hackers and can put other parts of your network at risk.
The way to change these values varies by device. For hosts, it is changed in the configuration file associated with the SNMP agent (we’ll examine the one for Linux systems when we actually configure an agent next month.). For other devices, such as routers, consult the documentation provided by the manufacturer.
In contrast to the complex data definitions, the set of SNMP operations that monitor and manage devices is quite limited, consisting of get (requests a value from device), set (specifies the value of a modifiable device parameter) and trap (sends a trap message to a specified manager).
Next month we’ll install an SNMP package that allows a Linux host to function as an SNMP agent that also includes commands to print the definition of nodes in a MIB as well as perform the above SNMP operations.
Æleen Frisch is the author of Essential System Administration. She can be reached at firstname.lastname@example.org