Hello Paolo, I'm currently using nfacctd to capture netflow accounting, for the purpose of identifying unexpected high traffic flows. (I happen to be using the print plugin, and parsing the text files to generate web reports, etc.) The netflow exporter in this case is a Cisco RSP720.
One thing I notice is that the accounting data ends up being "bursty." It makes sense to me that this is a natural result of the netflow accounting architecture on the RSP720, with the fact that flows can be expired at any time. In the beginning of a 300-second window, flows may be expired and exported which primarily covered the preceding 300-second period, and at the end of the current window, all active flows may suddenly be expired and exported, causing a "spike" in reported traffic. This actually seems to happen quite a bit, here's a random sample of total packets/sec and bits/sec for a network segment where the traffic levels are actually relatively stable: Time Ending Total Kpps Total Mbps 8/30/2013 11:01:33 941 6736 8/30/2013 11:00:29 415 2941 8/30/2013 10:59:25 1115 7865 8/30/2013 10:58:21 1229 9193 8/30/2013 10:57:17 127 420 8/30/2013 10:56:13 1313 9412 8/30/2013 10:55:09 946 6934 (NB the above is using 64-second mls aging and print refresh time, but the concept stands regardless of interval length) So the reason I'm writing is because in a previous life, I used a different netflow collector which simply dumped the netflow records to a flat file, and I wrote the scripts to aggregate the data. I saw the same burstiness in traffic rates due to the nature of netflow. At that time, I employed a strategy which seemed to do a very good job of smoothing out the burstiness. What I did was to pro-rate the byte & packet counts across time intervals. So for example, if we receive a netflow accounting record, duration 240 seconds, at 00:06:00, then I would count 1/4 of the packets & bytes to the current interval (05:00 - 09:59) and 3/4 of the packets & bytes to the prior interval (00:00 - 04:59). A downside is that you only get "half" of the data for the current interval, so full reporting for any given interval is delayed by 1x interval length. I'm interested in applying the pro-rating algorithm to nfacctd. I have no idea how I would do that in the code. Paolo, I'm curious your thoughts in this regard. Thanks, Ed
_______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists