[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).
Regards,
Chris
More information about the cisco-nsp
mailing list