[c-nsp] Sup2T - poor netflow performance

Chris Welti chris.welti at switch.ch
Fri Oct 18 10:27:50 EDT 2013

Am 18.10.13 14:05, schrieb Dobbins, Roland:
> On Oct 18, 2013, at 12:13 PM, "Rolf Hanßen" <nsp at rhanssen.de> wrote:
>> ip flow monitor <monitorname> input
>> ip flow monitor <monitorname> output
> If you're collecting both ingress and egress NetFlow on the same interface, this could be contributing to your issues - Cisco do not recommend doing this due to overflow issues (which could lead to punting).
ingress and egress on the same interface is a configuration officially 
supported by Cisco for the Sup2T. Escpecially for the Sup2T-XL/DFC4-XL 
which has separate netflow tables for ingress and egress, there should 
be no overflow issues due to this.
Still, netflow performance currently sucks on Sup2T (netflow export 
rate/CPU usage/any netflow CLI commands).
We're currently investigating with Cisco why this is the case. One of 
the things they said might cause this could be the lookup of collect 
fields which are done by CPU when exporting or displaying flows (with 
show flow monitor).

> Sampler configuration is covered in the Flexible NetFlow Command Reference for 15.x on cisco.com.
> And again, input ifindex should be obtained via 'match', not 'collect', in order to ensure that it's a key field.

just as a side note, while 'match' is fine for input ifindex, output 
ifindex should NOT be used as a match field in a netflow record for 
ingress netflow. That is only supported for egress netflow.
At the time of ingress netflow processing, the output ifindex is not 
known and will thus be NULL in the netflow table (at least on DFCs).
If you assign output ifindex as a collect field, the netflow table will 
be updated with the correct output ifindex once it is known (when a flow 
packet leaves another interface).


More information about the cisco-nsp mailing list