Am 18.10.13 14:05, schrieb Dobbins, Roland:
On Oct 18, 2013, at 12:13 PM, "Rolf Hanßen" <[email protected]> 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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
