Ask Slashdot: MRTG and IP Accounting

Webdude asks: "I run a server that has many IP aliases and have found a very strange thing: all the aliases receive data but all data is sent out through eth0. I have MRTG up and running but it doesn't help me because all traffic is going out eth0. I set up IP Accounting and found that it records the packets traveling properly but now my big question is how do I get MRTG (or something similar) to graph the stats that are in the IP Accounting tables???"

Comments

your SOLUTION

[Anonymous Coward]

The solution for your problem is here:
mydata.pl:
#!/usr/bin/perl

# mydata.pl
#
# parse linux 2.2.x ip-accounting file
# return data for use by mrtg
#
# line 1: data in
# line 2: data out
# line 3:
# line 4: hostname

use strict;

#modify these
my $hostname="www.break.org";
my $ipaccfile="/proc/net/ip_fwchains";

if($ARGV[0] eq "") { exit(1); }
my $linenr=$ARGV[0];

#read and parse correct line of ip_fwchains
sub get
{
my $find=shift;
my $return=0;
my $count=0;

open(FL,"$ipaccfile");
while() {
if(/[ ]+$find.*/) {
$count++;
if($count==$linenr) {
#match byte-counters in ip_acct file
/.*->.* - \d+ \d+ \d+ \d+ [ ]+ (\d+)/;
$return=$1;
last;
}
}
}

close(FL);
return $return;
}


my $in=&get("input");
my $out=&get("output");

print("$in\n$out\n\n$hostname\n");



and for your mrtg.cfg:
WorkDir: /home/httpd/html/mrtg
Interval: 5
Icondir: /mrtg/gif

Target[all]: `/root/mrtg/mrtg/mydata.pl 1`
MaxBytes[all]: 1250000
Title[all]: Total TCP/IP Traffic
PageTop[all]: Total TCP/IP Traffic

Here's why... (Routing tables)

[Anonymous Coward]

There are two processes going on here. A packet receiver and a transmitter.

The packet receiver listens for packets on eth0. If it finds a packet with a destination address matching one of the host's addresses, it accepts the packet, logs the address it came to, and passes it to the application layer.

When an application (web server in this case) sends data out, the kernel looks at the destination IP address, looks at the routing table, sees that the default route is eth0, so all packets go to eth0. So when using ip accounting, all outgoing packets are logged with a destination of eth0.

What you want to do is to log the SOURCE address, not the destination address. In order to do this you must use source-routing, so that your routing table routes based on the packet's source address instead of just the destination address. Add a route for packets with each source IP and a destination of the corresponding eth0 alias, and then your packets will be logged the way you wanted.

Check out IPAC.

[deicide]

Check out ipac ( http://www.comlink.apc.org/~moritz/ipa c.html) which can create text-based and gif/html graphs based on data from ip accounting/ipchains.

---Vitaliy.

MRTG and ip accounting

[dtmf]

MRTG uses snmp to graph its stats. I had to download and install the cmu-snmp-linux (look at freshmeat for the actual url) in order to get snmp to work. MRTG also needs to know what physical interface to monitor so you have to tell it in the config file. If you have multiple interfaces it gets a little tricky to figure out which one to monitor but it can be done.

Once you've got the snmp stuff installed you need to find out how many interfaces it sees:

# snmpwalk localhost public interfaces

You should see something like this:

A lot of text scrolling by real fast - look specifically for this:

interfaces.ifTable.ifEntry.ifOperStatus.1 = INTEGER: up (1)
interfaces.ifTable.ifEntry.ifOperStatus.2 = INTEGER: up (1)
interfaces.ifTable.ifEntry.ifOperStatus.3 = INTEGER: up (1)
interfaces.ifTable.ifentry.ifOperStatus.4 = INTEGER: down (0)

I have four interfaces (lo, eth0, eth1 and eth2 [three are up and eth2 is down])

Look farther down the list for the statistics on that port ( look for interfaces.ifTable.ifEntry.ifInOctets.1 = COUNTER: some-big-number-here - this line counts the packets that come in over interface 1) and chose which number (1, 2, 3, or whatever you have) to put in your mrtg.conf file.

My mrtg.conf file looks like this:

Target[domainname]: 3:public@domainname.here

I've set it to monitor interface 3 in this config line. You can have multiple configs so that you can monitor multiple interfaces. I have both my main ethernet interfaces being monitored.

Something else you may want to look at to accomplish accounting for ip stuff is ipac (look at freshmeat for a url). It doesn't use snmp but instead uses the proc filesystem and counters that you define [you can watch any sort of traffic you want: nntp, smtp, www, pop3, imap - in any direction that you specify] to create graphs that show you you much traffic you've had pass through that machine.

MRTG just counts the traffic currently going by the interface when your cron job kicks in and tells it to look at the interface you specify - it doesn't count all the traffic that went by during the time period between cron jobs. MRTG creates nicer graphs though. ;-)

ipac actually graphs the amount of packets that went by - it doesn't matter if there's no traffic going by when you run the stats-fetching tool (fetchipac).

Hope that helped.

Cricket & MRTG

[joe_90]

Firstly, you should probably upgrade to Cricket, as it is more flexible, easier to manage and under active development unlike MRTG.
( http://www.munitions.com/~jra/cricket/ )

As one of the previous posters mentioned, MRTG does indeed use SNMP to get its data. Now I'm assuming you use the CMU SNMP agent (or the UCD.. doesn't matter). You probably only have the MIB-II SNMP definitions supported by your agent.

What is probably happening is that your agent doesn't know anything about the data you are trying to collect. Now with Cricket or MRTG you can configure it to collect from a script. So you will probably need to write a script to ssh (or rsh) into the machine you are monitoring, collect the data and print it to stdout. Then it will happily graph that for you.

HTH HAND.

Joe
--

Re:MRTG uses SNMP

[Liem Bahneman]

However, some version of snmpd (cmu) do not
make accurate byte counts from /proc/net/ip_acct,
it uses a kludge to average all packet sizes to
308 bytes. So what you see with snmp may not be
accurate. We sent a modified snmp_vars.c that
correctly reported byte counts with snmp to cmu and I think they rolled it into versions > 3.5.

Version 3.3 didn't even bother reading /proc/net/ip_acct, too.

So beware with what you think is valid data reported with cmu's snmpd. Its probably wrong.

Just an FYI.