Network management applications
We begin this section by exploring the simplest SNMP management tools: the commands provided with the UCD SNMP package. These commands are useful for familiarizing yourself with SNMP, and they're also great for one-off checks of specific OIDs. Next, we look at MRTG, a program that generates historical graphs of SNMP values, and NOCOL, an event-based monitoring system. We conclude with some recommendations of what to look for when purchasing a commercial system.
The UCD SNMP tools
Even if your system comes with its own SNMP server, you may still want to compile and install the seven client-side tools, listed in
Table 20.4, from the UC Davis package.
in the UCD SNMP package
| Command | Function |
|---|---|
| snmpget | Gets the value of an SNMP variable from an agent |
| snmpgetnext | Gets the next variable in sequence |
| snmpset | Sets an SNMP variable on an agent |
| snmptable | Gets a table of SNMP variables |
| snmptranslate | Searches for and describes OIDs in the MIB hierarchy |
| snmptrap | Generates a trap alert |
| snmpwalk | Traverses a MIB starting at a particular OID |
In addition to their value on the command line, these programs are tremendously handy in simple scripts. It is often helpful to have snmpget save interesting data values to a text file every few minutes. (Use cron to implement the scheduling; see Chapter 9, Periodic Processes.)
snmpwalk is another useful tool. Starting at a specified OID (or at the beginning of the MIB, by default), this command repeatedly makes "get next" calls to an agent. This behavior results in a complete list of available OIDs and their associated values. Here's a sample snmpwalk of the host jaguar ("public" is the community string):
% snmpwalk jaguar public
system.sysDescr.0 = Linux jaguar 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT
1999
system.sysUpTime.0 = Timeticks: (88516617) 10 days, 5:52:46.17
system.sysName.0 = jaguar
system.sysLocation.0 = Second Floor Machine Room
interfaces.ifNumber.0 = 2
interfaces.ifTable.ifEntry.ifIndex.1 = 1
interfaces.ifTable.ifEntry.ifIndex.2 = 2
interfaces.ifTable.ifEntry.ifDescr.1 = "lo0"Hex: 6C 6F 30
interfaces.ifTable.ifEntry.ifDescr.2 = "eth0"Hex: 65 74 68 30
interfaces.ifTable.ifEntry.ifType.1 = softwareLoopback(24)
interfaces.ifTable.ifEntry.ifType.2 = ethernet-csmacd(6)
interfaces.ifTable.ifEntry.ifMtu.1 = 3924
interfaces.ifTable.ifEntry.ifMtu.2 = 1500
interfaces.ifTable.ifEntry.ifInOctets.1 = 12590602
interfaces.ifTable.ifEntry.ifInOctets.2 = 2287718531
interfaces.ifTable.ifEntry.ifInUcastPkts.1 = 75576
interfaces.ifTable.ifEntry.ifInUcastPkts.2 = 79730602
interfaces.ifTable.ifEntry.ifInErrors.1 = 0
interfaces.ifTable.ifEntry.ifInErrors.2 = 218
interfaces.ifTable.ifEntry.ifOutOctets.1 = 12591593
interfaces.ifTable.ifEntry.ifOutOctets.2 = 3374588125
...
In this example, we see some general information about the system, followed by statistics about the host's network interfaces, lo0 and eth0. Depending on the MIBs supported by the agent you are managing, a complete dump can run to hundreds of lines.
MRTG: The Multi-Router Traffic Grapher
MRTG, written by Tobi Oetiker at ETH in Zurich, collects SNMP data over time and then graphs it. It's written mostly in Perl. MRTG is invaluable for analyzing the historical use of your system and network resources.
MRTG runs regularly from cron and can collect data from any SNMP source. Each time the program runs, new data is stored and new graph images are created.
MRTG is free and offers several attractive features. First, it maintains a zero-maintenance, statically-sized database; the software stores only enough data to create the necessary graphs. For example, MRTG could store one sample every minute for a day, one sample every hour for a week, and one sample every week for a year. This consolidation scheme lets you maintain important historical information without having to store unimportant details or to consume your time with database administration.
Second, MRTG can record and graph any SNMP variable. You're free to collect whatever data you want. When combined with the UCD SNMP agent, MRTG can provide a historical perspective on almost any system or network resource.
The future of MRTG lies in a new package, RRDtool, by the same author. RRDtool is similar in concept to MRTG, but with improved data consolidation and graphing features. Unlike MRTG, RRDtool does not offer any data collection methods of its own. Instead, a separate piece of software must collect the data.
Currently, Jeff Allen's Cricket tool is the best choice for this role. Cricket is not limited to collecting SNMP data; it can pull in data from almost any network source. Since it is written in Perl, it's easy to add new data sources.
Tobi Oetiker's home page at ee-staff.ethz.ch/~oetiker provides links to the current versions of MRTG, RRDtool, and Cricket.
NOCOL: Network Operation Center OnLine
NOCOL is an event-driven management tool that's currently maintained by Vikas Aggarwal. Although it will not help you determine how much your bandwidth utilisation has increased over the last month, it will page you when your Web server goes down. Actually, NOCOL can be configured to page (or email) your operations staff after many kinds of events.
The distribution includes monitor programs that supervise a variety of common points of failure. You can whip up new monitors in Perl, or even in C if you are feeling ambitious. For notification methods, the distribution can send email, generate Web reports, view status with a curses interface, and use a dial-up modem to page you. As with monitor programs, it's easy to roll your own.
If you cannot afford a commercial network management tool, we suggest giving strong consideration to NOCOL. The software works very well for networks of less than 100 hosts and devices. You can read more at www.netplex-tech.com.
Commercial management platforms
Hundreds of companies sell network management software, and new competitors enter the market every week. Instead of recommending the hottest products of the moment (which may no longer exist by the time this book is printed), we'll try to identify the features you should look for in a network management system.
Data gathering flexibility: It's important for management tools to be able to collect data from sources other than SNMP. Many packages include the ability to gather data from almost any network service. For example, some packages can make SQL database queries, check DNS records, and connect to Web servers.
User interface quality: Expensive systems often offer a custom GUI or a Web interface. The most well-marketed packages today all tout the ability to understand XML templates for data presentation. Although the UI often seems like just more marketing hype, it is important to have an interface that relays information clearly, simply, and comprehensibly.
Value: Some management packages come at a stiff price. HP's OpenView is both one of the most expensive and one of the most widely adopted network management systems. For many corporations, there is a definite value in being able to say that your site is managed by a high-end commercial system. If that isn't so important to your organisation, you should look at the other end of the spectrum for free tools like MRTG and NOCOL.
Automated discovery: Many systems offer the ability to "discover" your network. Through a combination of broadcast pings, SNMP requests, ARP table lookups, and DNS queries, they are able to identify all your local hosts and devices. All the discovery implementations we have seen work pretty well, but none are very accurate on a complex (or heavily firewalled) network.
Reporting features: Many products can send alert email, activate pagers, and automatically generate tickets for popular trouble-tracking systems. Make sure that the platform you choose allows for flexible reporting; who knows what electronic devices you will be dealing with in a few years?
Configuration management: Some vendors step far beyond monitoring and alerting. They offer the ability to manage actual host and device configurations. For example, CiscoWorks provides an interface that lets you change a router's configuration in addition to monitoring its state with SNMP. Because device configuration information allows for a deeper analysis of network problems, we predict that many packages will develop along these lines in the future.
4%
4%
