Hey there, We've been looking at using nfacctd as a NetFlow connector internally at our company for a little while now, but we've come across something a little bit disturbing during testing.
We have a Cisco 7301 exporting flows to a server running nfacctd, which we then insert into a MySQL database for use in generating statistics at a later date. The router is configured to use NetFlow v5 for exporting data (as we don't need any visibility further than number of bytes to and from a given IP address.) As a side note, if it helps, the datagrams exported from the 7301 to the collector have around 30 flows in them (per datagram.) When inserting the data we generally don't have any issues, all the counters match up to the data downloaded or uploaded from a client behind the 7301, which is awesome. Occasionally, however, we get data from the past coming through and being inserted into the database. For example, if the current date was the 7th of April 2008 (2009-04-07), every now and again we have an entry added into the database for the 16th of February 2008 (2009-02-16.) Originally I thought that it may be the flows exported from the 7301 having the time stamp set incorrectly, but after grabbing the flows on the way into the collector (using tcpdump) we've found that the timestamp is set correctly. When running nfacctd in debug mode we can see that when the flow is being inserted into the database its timestamp differs from what the flow has in it. For example (i've obfuscated the IP addresses here, but everything else is in tact.) * *DEBUG ( download/mysql ): INSERT INTO `acct_v5` (stamp_updated, stamp_inserted, vlan, ip_dst, src_port, dst_port, tos, ip_proto, agent_id, class_id, mac_src, mac_dst, ip_src, packets, bytes, flows) VALUES (FROM_UNIXTIME(1239081310), FROM_UNIXTIME(1234783800), 0, 'xxx.xxx.xxx.xxx', 0, 0, 0, 'ip', 0, 'unknown', '0:0:0:0:0:0', '0:0:0:0:0:0', '0.0.0.0', 18, 16135, 0) DEBUG ( download/mysql ): INSERT INTO `acct_v5` (stamp_updated, stamp_inserted, vlan, ip_dst, src_port, dst_port, tos, ip_proto, agent_id, class_id, mac_src, mac_dst, ip_src, packets, bytes, flows) VALUES (FROM_UNIXTIME(1239081310), FROM_UNIXTIME(1239078600), 0, 'yyy.yyy.yyy.yyy', 0, 0, 0, 'ip', 0, 'unknown', '0:0:0:0:0:0', '0:0:0:0:0:0', '0.0.0.0', 3, 744, 0) The first flow is the one which is inserted with the stamp_inserted set to a past timestamp, and the second is the next flow received, which has the correct timestamp set. These were both inserted at the same time into the database, and were contained in the same datagram coming from the 7301, but the timestamps differ. To make matters even more confusing the 7301 was not even powered on in February. I was wondering if anyone else has experienced any similar issues, and if so, how were they resolved? Or is this maybe a bug? I love nfacctd as it has incredible performance when we throw a lot of flows at it (we had it running at 21,000 flows per second with only 20% CPU), but this issue would be a show stopper for me being able to use it in production. Thank you for your time :) -- Peter
_______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
