Hi Brent, >From what I've read on the SUP720 and RSP720, they do not support netflow sampling for creation/update, they only support "sampling" on export. I think the way that works is they randomly skip exporting some of the records. So I don't think that would actually impact the overflow issue... but I guess I should double-check that as an option...
Thanks for the idea, Ed On Fri, May 24, 2013 at 3:47 PM, Brent Van Dussen <b...@microsoft.com> wrote: > Hi Ed,**** > > ** ** > > Does your RSP720 support sampled netflow by chance?**** > > ** ** > > -Brent**** > > ** ** > > *From:* pmacct-discussion [mailto:pmacct-discussion-boun...@pmacct.net] *On > Behalf Of *Edward Henigin > *Sent:* Friday, May 24, 2013 1:40 PM > *To:* pmacct-discussion@pmacct.net > *Subject:* [pmacct-discussion] Tips on dealing with overflowing 32-bit > fields?**** > > ** ** > > Hi y'all,**** > > ** ** > > I'm hoping that someone has some experience that might help.**** > > ** ** > > I'm using nfacctd to collect flows from a Cisco RSP720. After banging my > head against the keyboard for a few days, I realized I should have > configured pmacct with --enable-64bit. After re-building with that, > accuracy is dramatically improved, but I'm still finding bytes being > under-reported in numerous intervals.**** > > ** ** > > I believe the problem I'm running into is that the RSP720 is collecting > its data in a 32-bit field and that field is wrapping -- or, the netflow v5 > packet uses 32 bits for bytes, and it's wrapping on export. In any case, I > think the byte count is lost before it leaves the Cisco.**** > > ** ** > > I'm using the "interface-destination" flow mask. I've tried using > "interface-destination-source" but that causes some CPU load on the Cisco > and flow creation failures.**** > > ** ** > > To have the highest resolution and to minimize the risk of netflow > creation failures, all the timers are set to the lowest:**** > > ** ** > > enable timeout packet threshold**** > > ------ ------- ----------------**** > > normal aging true 32 N/A**** > > fast aging true 32 7**** > > long aging true 64 N/A**** > > ** ** > > 2**32 bytes in 64 seconds is only 537 Mbps. Doesn't work very well for > multi-gigabit traffic servers.**** > > ** ** > > Does anyone have any ideas on how to reduce or eliminate counter wrap on > the Cisco side for the bytes counter?**** > > ** ** > > Many thanks,**** > > ** ** > > Ed**** > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists >
_______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
