Date: Wed, 6 Jul 2005 09:11:08 -0400 (EDT) From: John Von Essen <john@essenz.com> To: freebsd-isp@freebsd.org Subject: Re: Multiple IP MRTG or Similar Message-ID: <20050706085010.I16800@beck.quonix.net> In-Reply-To: <001801c5821e$c455e340$de0a0a0a@visionsix.com> References: <3b88b80a0507051933f4750f3@mail.gmail.com><06ef01c581f6$c54fb3c0$de0a0a0a@visionsix.com> <1120637769.16870.6.camel@tessa.mysmt.net> <001801c5821e$c455e340$de0a0a0a@visionsix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-isp > To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050706085010.I16800>