On 05/02/14 12:08, Dobbins, Roland wrote:
On Feb 5, 2014, at 6:58 PM, Phil Mayers <[email protected]>
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.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
