[c-nsp] Sup2T netflow problems

[Phil Mayers]

On 05/02/14 12:08, Dobbins, Roland wrote:
>
> On Feb 5, 2014, at 6:58 PM, Phil Mayers <p.mayers at imperial.ac.uk>
> wrote:
>
>> That can't be. Sup2T has "operationally useful netflow". I read it
>> somewhere...
>
> That means it isn't broken by design, as in pre-EARL8 Sups & DFCs.

It could *be* a hardware problem or implementation decision. Unlikely in 
this case I'll grant you, but the number and variety of EARL8 netflow 
bugs is increasing at this point, based on my own experience and the 
traffic on this list.

I'm by no means confident that Cisco have a handle on how to solve 
timestamp skew on N7k/M1 at this stage, for example.

> It doesn't mean there can't be bugs . . .

There *are* bugs. And for some people, those bugs might trump the 
on-paper superior capabilities of EARL8, at least until they're fixed. 
And we all know how long that can take.

Speaking personally: sup720 handled our traffic fine. We changed 
platforms because we needed better 10G port density, and right now, 
we've paid for that with inferior netflow.

So, for me, your comments just aren't true. Most likely there is some 
unspoken qualification that you assume everyone aware of e.g. 
"operationally useful netflow when sampling" or "in the DFZ" or "if you 
flow churn rate exceeds X". If that's the case, do please spell them out.