On 27/03/13 12:08, Sam wrote:
On Wed, March 27, 2013 12:49 pm, Phil Mayers wrote:
If it wasn't so irritating/tragic, this would be hilarious. People have
repeatedly said "sup2T has operationally useful netflow" and yet it
turns out to be *less* capable than sup720.
I agree on this, however I don't really see a problem in sampling and
reducing the export rate by doing so. We get very accurate data out of
sampled netflow data from sup2t, much more accurate than the data we
obtained from sup720.
We never ever had an issue in more than a year that we run our sup2t's
with sampled netflow and NDE limits (to be honest the limits never dropped
a single export so far).
It kind of depends on what you want to do with your netflow.
If you want it for statistical analysis, I agree that sampling can be
fine; the statistics can give you confidence bounds, and you sample at a
rate appropriate for whatever level of confidence you need.
We do use netflow for a kind of "billing" (actually quotaing) and
sampling would be OK there, but we also use it for something rather
different: we capture all flows and use it like a poor mans "back in
time" tcpdump - we get weird problems reported with crazy systems and
we're able to see the packets, ICMP errors and so on when the problem
actually occurred.
This has proven INSANELY useful in our environment, and losing it would
be a serious loss of capability.
Obviously lots of people won't have this need, but it's the reason we
would avoid sampling. Maybe it's an unreasonable thing to want - but we
do want it ;o)
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
