Another alternative would be to install a Host sFlow agent (http://host-sflow.sourceforge.net/) on your router. Traffic monitoring is performed using the iptables statistics module and ULOG. http://blog.sflow.com/2010/12/ulog.html A few comments about the solution: 1. It is extremely lightweight and the data analysis can be shifted to a different machine, further reducing the overhead on the router. 2. Sampling works well for identifying the top 5 sources 3. Host sFlow also exports cpu, memory, disk etc. statistics so you can track router load. 4. You can perform detailed analysis on the top talkers to see what they are doing. Peter On Wed, Jul 25, 2012 at 3:19 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Mon, Jul 23, 2012 at 03:27:08PM -0700, Yucong Sun (叶雨飞) wrote: >> Thanks for the reply, Yeah I'm aware all of that you have mentioned, >> please allow me to elaborate my requirements a little more. >> >> I have about 500 IPs behind a router, and I want have something on my >> router to monitor the ingress bps/pps to each specific IP. And I would >> like to have a cron job that scans the result and find the top 5 IP >> with most bps/pps and also do some action against it, calling a >> script, sending a email etc. >> >> So, It seems none of the existing stuff allows me to do this. > > You can add one nfacct rule per IP and then use the nfacct utility to > periodically dump the counters and find for top IPs. Some shell script > should allow want you need. You can also develop your own daemon with > native libnetfilter_acct interfaces to periodically pull the counters > and perform the processing you need. > >> the easiest brain-dead solution I can think of is to just create a chain >> with 500 rules in it, and have a cron job to cacluate the bytes >> difference every time it executes. > > Instead of this, I'd go nfacct. > >> Obviously, this will introduce a >> lot of delays, I'm hoping to have something that basically don't >> affect performance too much and or something to just generates a table >> of ip / accumulative packets / accumulative bytes, and I will be able >> to work with that. > > Well, how much is "a lot of delay". I think your performance concerns > need real numbers. I don't think that will be too much as you mention. > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
