Hello, Yes, it is trickier with the aggregator.. the pcap syntax is really powerful and definetely is a must to have an option to read the pcap and aggregate filters from a file. I am not sure about CPU load though.. If the aggregator consumes less CPU than pcap filters, it is good to have a reverse option... I haven't tested which one (aggregate_filters or networks_file aggregator) is less stressful to the CPU under heavy loads (over 100Mbits/s or 15000 packets/s).
Paolo Lucente wrote: > i see your point. And was wondering whether a better solution could be > to add a feature which allows the filter directives (aggregate_filter, > pcap_filter) to read the well-formatted pcap filter from a file - like: > > aggregate_filter: 'file:/path/to/a/filter' > > It could come handy to generate and update filters (which could be > read at the next startup of the daemon). > > The point here is that the solution should be generic in order to be > useful: a flat file that lists some prefixes just eases your life to > either include or exclude them from somewhere - that's it; a filter > expression is more featureful (which is not necessarily a good thing, > as it also translates in added complexity) but fits in pretty much > every scenarios. > > The networks_file directive is an aggregator rather than a pure filter > (it does a bit of filtering though). Excluding prefixes then poses the > problem of what to do with the IP addresses that would pass the filter > - should they get aggregated somehow? >> >> It would be nice to have an option to exclude lots of networks from >> accounting -> just the opposite of networks_file. It is not very practical >> to write/generate huge pcap filters if you want to exclude 100 or more >> networks from pmacct. -- Anton Glinkov network administrator _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
