172
Notice that you still need to give MaxBytes and AbsMax in bytes. Many more keywords are available. Only the most common have been described here, but these
should be more than enough to meet your initial needs. See the mrtg sample configuration file and documentation for others.
Once you have the configuration file, use indexmaker to create a main page for all the interfaces on a device. In its simplest form, you merely give the configuration file and the destination file:
bsd2 indexmaker mrtg.cfg usrlocalwwwdatamrtgindex.html
You may specify a router name and a regular expression that will match a subset of the interfaces if you want to limit what you are looking at. For example, if you have a switch with a large number of
ports, you may want to monitor only the uplink ports.
Youll probably want to run mrtg manually a couple of times. Here is an example using the configuration file test.cfg:
bsd2 mrtg test.cfg Rateup WARNING: .rateup could not read the primary log file for testing
Rateup WARNING: .rateup The backup log file for testing was invalid as well Rateup WARNING: .rateup Cant remove testing.old updating log file
Rateup WARNING: .rateup Cant rename testing.log to testing.old updating log f
ile
The first couple of runs will generate warning messages about missing log files and the like. These should go away after a couple of runs and can be safely ignored.
Finally, youll want to make an appropriate entry in your contab file. For example, this entry will run mrtg every five minutes on a FreeBSD system:
0,5,10,15,20,25,30,35,40,45,50,55 usrportsnetmrtgworkmrtg- 2.8.12r
unmrtg usrportsnetmrtgworkmrtg-2.8.12runmrtg.cfg devnull 21
This should be all on a single line. The syntax is different on some systems, such as Linux, so be sure to check your local manpages.
8.4.2 rrd and the Future of mrtg
The original version of mrtg had two deficiencies, a lack of both scalability and portability. Originally, mrtg was able to support only about 20 routers or switches. It used external utilities to perform SNMP
queries and create GIF images—snmpget from CMU SNMP and pnmtogif from the PBM package, respectively.
These issues were addressed by MRTG-2, the second and current version of mrtg. Performance was improved when Dave Rand contributed rateup to the project. Written in C, rateup improved both
graph generation and handling of the log files.
The portability problem was addressed by two changes. First, Simon Leinens Perl script for collecting SNMP is now used, eliminating the need for CMU SNMP. Second, Thomas Boutells GD library is
173
now used to directly generate graphics. At this point, mrtg is said to reasonably support querying 500 ports on a regular basis.
As an ongoing project, the next goal is to further improve performance and flexibility. Toward this goal, Tobias Oetiker has written rrd Round Robin Database, a program to further optimize the
database and the graphing portion of mrtg. Although MRTG-3, the next version of mrtg, is not complete, rrd has been completed and is available as a standalone program. MRTG-3 will be built on
top of rrd.
rrd is designed to store and display time-series data. It is written in C and is available under the GNU General Public License. rrd stores data in a round-robin fashion so that older data is condensed and
eventually discarded. Consequently, the size of the database stabilizes and will not continue to grow over time.
8.4.3 cricket
A number of frontends are available for rrd, including Jeff Allens cricket. Allen, working at WebTV, was using mrtg but found that it really wasnt adequate to support the 9000 targets he needed to
manage. Rather than wait for MRTG-3, he developed cricket. At least superficially, cricket has basically the same uses as mrtg. But cricket has been designed to be much more scalable. cricket is
organized around the concept of a configuration tree. The configuration files for devices are organized in a hierarchical manner so the general device properties can be defined once at a higher level and
inherited, while exceptions can be simply defined at a lower level of the hierarchy. This makes cricket much more manageable for larger organizations with large numbers of devices. Since it is designed
around rrd, cricket is also much more efficient.
cricket does a very nice job of organizing the pages that it displays. To access the pages, you will begin by executing the grapher.cgi script on the server. For example, if the server were at
172.16.2.236 and CGI scripts were in the cgi-bin directory, you would point your browser to the URL http:172.16.2.236cgi-bingrapher.cgi. This will present you with a page organized around types of
devices, e.g., routers, router interfaces, switches, along with descriptions of each. From this you will select the type of device you want to monitor. Depending on your choice, you may be presented with a
list of monitored devices items or with another subhierarchy such as that shown in
Figure 8-7 .
Figure 8-7. cricket router interfaces
174
You can quickly drill down to the traffic graph for the device of interest. Figure 8-8
shows an example of a traffic graph for a router interface on a router during a period of very low usage but you get the
idea, I hope.
Figure 8-8. Traffic on a single interface
175
As you can see, this looks an awful lot like the graphs from mrtg. Unlike with mrtg, you have some control over which graphs are displayed from the web page. Short-Term displays both hourly and
daily graphs, Long-Term displays both weekly and monthly graphs, and Hourly, Daily, and All are just what you would expect.
[2] [2]
mrtg uses Daily to mean an hour-by-hour plot for 24 hours. cricket uses Hourly to mean the same thing. This shouldnt cause any problems.
Of course, you will need to configure each option for mrtg to work correctly. You will need to go through the hierarchy and identify the appropriate targets, set SNMP community strings, and add any
descriptions that you want. Here is the interfaces file in the router-interfaces subdirectory of the cricket-config directory, the directory that contains the configuration tree. This file corresponds to the
output shown in
Figure 8-8 .
target --default-- router = NLCisco
snmp-community=public target Ethernet0_0
176
interface-name = Ethernet00 short-desc = Gateway to Internet
target Ethernet0_1 interface-name = Ethernet01
short-desc = 172.16.1.024 subnet target Ethernet0_2
interface-name = Ethernet02 short-desc = 172.16.2.024 subnet
target Ethernet0_3 interface-name = Ethernet03
short-desc = 172.16.3.024 subnet target Null0
interface-name = Null0 short-desc =
While this may look simpler than an mrtg configuration file, youll be dealing with a large number of these files. If you make a change to the configuration tree, you will need to recompile the
configuration tree before you run cricket. As with mrtg, you will need to edit your crontab file to execute the collector script on a regular basis.
On the whole, cricket is considerably more difficult to learn and to configure than mrtg. One way that cricket gains efficiency is by using CGI scripts to generate web pages only when they are needed
rather than after each update. The result is that the pages are not available unless you have a web server running on the same computer that cricket is running on. Probably the most difficult part of the
cricket installation is setting up your web server and the cricket directory structure so that the scripts can be executed by the web server without introducing any security holes. Setting up a web server and
web security are beyond the scope of this book.
Unless you have such a large installation that mrtg doesnt meet your needs, my advice would be to start with mrtg. Its nice to know that cricket is out there. And if you really need it, it is a solid package
worth learning. But mrtg is easier to get started with and will meet most peoples needs.
8.5 RMON
As we saw in the last chapter, SNMP can be used to collect network traffic at an interface. Unfortunately, SNMP is not a very efficient mechanism in some circumstances. Frequent collection of
data over an overused, low-bandwidth WAN link can create the very problems you are using SNMP to avoid. Even after you have the data, a significant amount of processing may still be needed before the
data is in a useful form.
A better approach is to do some of the processing and data reduction remotely and retrieve data selectively. This is one of the ideas behind the remote monitoring RMON extensions to SNMP.
RMON is basically a mechanism to collect and process data at the point of collection. RMON provides both continuous and offline data collection. Some implementation can even provide remote
packet capture. The RMON mechanism may be implemented in software on an existing device, in dedicated hardware such as an add-on card for a device, or even as a separate device. Hardware
implementations are usually called RMON probes.
