Hi Ed, Although you might be running into other typical C7600 issues with NetFlow, ie. inaccuracy introduced by NetFlow TCAM space exhaustion (especially if your RSP720 is not XL series), I concur with Brent suggestion to first of all try enabling sampling. Also i'd definitely recommend to switch to its packet-based version (by default it's time-based) (*, see NetFlow sampling section). The pointed document should clarify how packet-based sampling is working; also, by having collected myself NetFlow from C7600 boxes at some ISPs, i can confirm you need to renormalize counters (factor in the sampling rate: "nfacctd_renormalize: true" config directive) in order to get actual values - so original flow bytes/packets counters must be getting manipulated somewhere before/upon NetFlow export at the router.
Speaking of pmacct: --enable-64bit is enabled by default since 0.14.3 as, as you were correctly pointing out, it makes sense to. Cheers, Paolo (*) http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/nde.html#wp1164308 On Fri, May 24, 2013 at 04:39:58PM -0500, Edward Henigin wrote: > 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 <[email protected]> wrote: > > > Hi Ed,**** > > > > ** ** > > > > Does your RSP720 support sampled netflow by chance?**** > > > > ** ** > > > > -Brent**** > > > > ** ** > > > > *From:* pmacct-discussion [mailto:[email protected]] *On > > Behalf Of *Edward Henigin > > *Sent:* Friday, May 24, 2013 1:40 PM > > *To:* [email protected] > > *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 _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
