[c-nsp] Sup2T - poor netflow performance

[Phil Mayers]

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)