[c-nsp] why there are no plans for A903-RSP2B-240 please?????

[Chris Welti]

Hi Gert,

Am 23/07/14 um 09:58 schrieb Gert Doering:
> On Tue, Jul 22, 2014 at 11:03:46PM +0200, Mark Tinka wrote:
>> We're deploying quite a bunch of the C6880's in core switch
>> roles. So very simple, pure Layer 2 switching, no fancy IP
>> or MPLS features enabled.
>>
>> It's a good box, based on the SUP2T, so lots of software
>> features Day One.
>
> Do you use netflow export on that one?  From what I've read so far
> on this list, netflow export on Sup2T seems to be "not without issues",
> in particular, high CPU load.

After about a year of working together with Cisco on the Netflow export issues
on the Sup2T (still ongoing), I've given up on netflow export on the Sup2T.
The limit we have seen is about 15k flows/s on the Sup and roughly 12k flows/s
on the linecard DFCs (that is with basically full CPU load).
There is no sign that this will significantly improve in the next few years.
The biggest problem is of course the CPU load on the Sup, which makes the whole
CLI very laggy and doesn't leave much room for anything else that uses the CPU.
So if you use netflow export make sure you don't configure any flow monitors on the
on-board interfaces. Just use DFC equipped linecards and let them handle
the export. Of course that doesn't help for egress flows that originate on one
of the Sup2T on-board interfaces, as netflow processing always happens on the
ingress ports, also for egress.
On the bright side, they have optimized the code for netflow analysis on the
CLI a bit, so certain show flow monitor commands will not take hours/freeze as they did before :)
(Although that code is still being debugged and is not yet in any official releases...).

> We have no Sup2T or 6880, so I have no personal experience, but I'm
> very much interested to hear whether this has been solved.

As far as I've heard from Cisco, the netflow issues are still the same on the C6880,
as it is based on the Sup2T code, so I assume no progress on that front.
IMHO the problem seems to be the software; the change from traditional netflow
to flexible netflow killed the export performance/CPU usage.
Why they didn't dedicate a seperate powerful CPU/ASIC that does the netflow export when
they spent so much on the hardware that generates the netflow table, is beyond me.

> (I'm not sure where our journey is headed to.  One of the killer features
> I'm still looking for is "netflow with source mac addresses in it,
> implemented by someone who understands packets" - not available at all
> on IOS XR, completely unreasonable on Sup2T...)

We're currently looking at external boxes that generate and export netflow records
from a port mirror or fiber tap.
(e.g. Cisco NGA3240, Invea Tech Flowmon Probe, Emulex NGA3040 or Ntop Nprobe/Nbox).
That seems to be the only way to go right now if you want to have decent unsampled
netflow. Unfortunately you then lose routing/next-hop/interface information.
If anyone has experiences with such boxes, please let me know.

Chris