Multiple IP MRTG or Similar

[John Von Essen]

I have recently had this problem with metering bandwidth across multiple
IP's on the same interface in a FreeBSD box (and solved it!)

First I tried bandwidthd - nice but it had a few problems. For starters,
under FreeBSD 4.11 it was using 98% CPU. It was also difficult to
customize for each client.

Then I stumbled across pmacctd (its in ports) and this I liked because it
was just a raw engine that allowed me to capture the data. From there I
could do whatever I wanted with that data.

pmacctd stores data points in a sql database, or it can do it memory. I
went with MySQL storage. It monitors all packets and aggregates by IP, or
port, (or whatever you want). Here is an example of what the data looks
like in MySQL:

|SRC MAC|DST MAC|SRC IP|DST IP|SRC PORT|DST
PORT|PROTO|PACKETS|BYTES|TIME-INSERTED|TIME-UPDATED

| 0:0:0:0:0:0 | 0:0:0:0:0:0 | 146.145.66.91   | 66.63.179.22    |       53
| 1291 | ip | 1 | 212 | 2005-07-06 08:40:00 | 2005-07-06 08:49:16 |

| 0:0:0:0:0:0 | 0:0:0:0:0:0 | 66.63.179.22    | 146.145.66.91   |     1291
| 53 | ip | 1 | 57 | 2005-07-06 08:40:00 | 2005-07-06 08:49:16 |

So it records total bytes transfered in 10 minute blocks (TIME-INSERTED is
the 10 minute block). When the 10 minute block is done, I just add up all
the data for the given IP's. I bill on total data transfer, so I'm done.
If I need transfer rates, I could just compute the avg. transfer rate for
that 10 minute interval.

pmacctd uses very little system resources. There is only one downside
though.... It generates a ton of mysql records. So much, that every hour
I do my computations and export to a text file for the IP/client, then
delete the data in Mysql. So I only have ~ the last hour in sql at any
given time. If I didn't do this, after a few days, I would over a 100,000
records!

I have actually made a set of pretty portable perl scripts which takes the
data and makes the web GUI for the IP/client. Check out
http://146.145.66.90/ip66-92/ (Login as guest/let4me)

If anyone wants the scripts, just let me know, you just need perl with
GD::Graph.

NOTE: If the ports version of pmacctd is not 0.8.8 - dont use it, there is
a bug. The bug has been fixed in 0.8.8 which you can download from:
http://www.ba.cnr.it/~paolo/pmacct/

-john


On Wed, 6 Jul 2005, Lewis Watson wrote:

> > Hi my expirience is that bandwithd does a terrible job, it sets your
> > interface in promisious mode if I'm not mistaken and keeps it's data in
> > ram. use it only for investigation or test environment's not on
> > production systems (my advice.)
> >
> > -Erik.
>
> Hi,
> I would like to share some of our experiences with Bandwidthd. As I mentioned in my previous email, Netflow and Bandwidthd are certainly two vastly different applications. However, we have used and tested Bandwidthd in a variety of small and small-medium size environments. In the end we found no problem running Bandwidthd and in each case it did exactly what we needed it to do.
>
> We have ran Bandwidthd on a FreeBSD firewall/ bridge with over 2000 client machines passing traffic through it daily for six months. The clients all were connected via T1 circuits or better. We experienced no problems using the conventional logs it generated.
>
> We have also had Bandwidthd running for about two years on a much smaller network. Initially there was an issue on this host with FreeBSD but an update resolved the bug that was found a few months ago in regards to the logs not being able to generate the stats after rebooting the server.
>
> There have been other situations where we have used Bandwidthd and the results were always similar to the above examples.  You can disable promiscuous mode on startup, otherwise I would probably leave it alone as well. The new version of bandwidthd gives the option to store the stats in PostgreSQL or in memory via text files. There is not much in the way of configuration unless you edit the src directly - (we added a line to include a css file and a few cosmetic changes) I think the config file is much simpler to use than MRTG, which was another issue the user had mentioned in the original email.
>
> This is just the luck we have had with Bandwidthd... I have no idea if it has ever worked for anyone else.
> Take care,
> Lewis Watson
>
> _______________________________________________
> freebsd-isp at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
> To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
>
>