On 18/02/14 10:55, Dobbins, Roland wrote:
On Feb 18, 2014, at 5:48 PM, Phil Mayers <[email protected]>
wrote:
AFAIK nfdump uses the start/end time in the flows to calculate pps,
so would this matter? Or is it a result of the sampling maths?
It has to do with long flows - flows aren't exported from the
router/switch until they're terminated. Be sure your active flow
timer is set to 1m/60s, and your inactive flow timer set to 5s.
Otherwise, you'll have all these false peaks and valleys from your
stats being backlogged up to 30m, which is the default for the active
flow timer.
Not quite what I was asking. I'm familiar with the basic operation of
netflow, but thanks for the explanation ;o)
Aaron reported his netflow was reporting too-high spikes. How would
shorter flow timeouts - which equals high-frequency reporting
bins/windows at the collector - result in *lower* pps counters?
I can only see this being the case of the collector doesn't honour
start/end times, and does something dumb like assuming end time ==
reception time. AFAIK that's not the case with nfdump.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
