Hi Peter, It smells like something we recently came across while dealing with a Cisco 800 series (running an IOS version which was showing some vintage). Can you post me privately an integral dump (libpcap format) of one or a few NetFlow datagrams which are originating this behaviour? Seeing also your configuration can help.
Cheers, Paolo On Wed, Apr 08, 2009 at 09:31:38AM +0930, Peter Adkins wrote: > 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
