Monitor Linux routers and firewalls with MRTG
Thomas Nooning CCNA, CCDA
Published: 01 Aug 2002 08:40 BST
The basic configuration file will look something like this:
Target[192.168.66.72.1]: 1:c1sc0@192.168.66.72
MaxBytes[192.168.66.72.1]: 1250000
Title[192.168.66.72.1]: RTR2: Ethernet0/0
PageTop[192.168.66.72.1]: Traffic Analysis for Ethernet0/0
These are just a few of the many options that can be placed into the MRTG configuration file. The first value here is Target. Inside the brackets is a unique name that will allow separate options for multiple devices and interfaces. Then, we have what will actually be providing the data, in this case, SNMP.
Next, we have the MaxBytes option. This is how the upper end is configured, and it's what percentage values are based on. It will vary between mediums and targets, depending on what you are polling. The next two options are for the HTML and act as descriptors.
Local scripts provide another way to get information to MRTG. These can range from simple to complex shell and Perl scripts. We'll look at how to do a simple shell script that will provide MRTG with data on packets inbound to an iptables firewall.
First, we will create the script, /usr/local/mrtg/iptables-in:
#!/bin/bash
IPTABLES="/sbin/iptables"
UPTIME="/usr/bin/uptime"
$IPTABLES -nvxL | grep INPUT | awk '{ print $5 }'
$UPTIME | awk '{ print $3, $4, $5 }'
This script will pull the number of packets it has accepted from the INPUT rule. It uses grep to search for the line containing INPUT and prints only the fifth value, which in this case is the number of packets processed. The uptime command is used so that MRTG will know how much time has passed between each value and can chart it over a period of time.
The mrtg.cfg will then look something like this:
WorkDir: /var/www/mrtg
Target[in_packets]: '/usr/local/mrtg/iptables-in'
MaxBytes[in_packets]: 1500
Title[in_packets]: Inbound packets
PageTop[in_packets]: Inbound Packet Stats
This is similar to the configuration used for SNMP above; however, we are pointing the target to an external script called iptables-in. We are also setting a fairly arbitrary MaxBytes setting since we are dealing with packets as opposed to bits or bytes. This will vary from system to system and a few different values may need to be tried. Although this is a rather simple example, it should give you an idea of what is possible with MRTG. Any data you can gather via the command line can be imported into MRTG and graphed in real time.
Running MRTG
Once MRTG has been installed successfully, you will need to configure it to run on your system. MRTG can be run manually as follows:
/usr/bin/mrtg /etc/mrtg.cfg
MRTG updates its log files every time it is run. The first two times, all the files will not have been created and you may see errors. These can be ignored, but anything you see on the third time around will probably warrant closer investigation.
It is a good idea to configure cron to run the program, as MRTG will need to execute often to poll devices and gather data. The standard interval is five minutes, but you can change it to fit your particular needs. Place an entry in /etc/crontab giving the interval, user to run as, path to mrtg, and the path to mrtg.cfg like this:
*/5 * * * * root /usr/bin/mrtg /etc/mrtg.cfg
Once MRTG is configured and running, all you will need to do is access the pages through a Web browser. You may want to tweak the HTML manually to do such things as index multiple devices and enable auto-refresh.
Summary
MRTG is a powerful and extensible tool that will allow you to graph network links and system information over a configurable period of time. Utilizing SNMP, local scripts, or a combination of the two, MRTG allows you to easily monitor your devices. Such things as trends, traffic spikes, and slow periods are easy to detect with a visual representation. MRTG does this in excellent form, outputting data in HTML and PNG formats viewable through a Web browser. MRTG doesn't have all the bells and whistles of commercial monitoring software, but it does the job well and is definitely worth considering as part of your network monitoring activities.
Have your say instantly in the
Tech Update forum.
Find out what's where in the new Tech Update with our
Guided Tour.
Let the editors know what you think in the
Mailroom.
Previous
Did you find this article useful?
131 out of 323 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
Full Talkback thread
1 comment
