[c-nsp] C6K, SUP720, 12.2(33)SXI, CoPP, glean

[John.Herbert at ins.com]

Ok, so apologies if I'm repeating things you know very well already...

Hardware CoPP for CEF Glean is disabled by default, so assuming you have enabled hardware CoPP, if you chose to enable glean rate-limiting (with the "mls rate-limit unicast cef glean <pps> <burst>" command) then presumably you put values in that command to determine the limits. If you're dropping cef glean traffic under normal usage, then (ignoring potential IOS bugs) that suggests that your limits are too low perhaps?

To be clear (and I think from what you've said, you already know this), the CEF Glean RL includes traffic that's punted to the CPU because it needs an ARP to be performed to complete the next hop adjacency, but should not affect the ARP request itself. However, if you are dropping the glean packets that would have generated the ARP request in the first place then I can see how that could spiral out of control quickly by generating more glean packets because of the lack of ARP entry.

If in doubt (and again, you may have done this before starting on the CoPP work), it may be worth either getting some netflow data to identify if you have excessive cef glean traffic, and/or set up a monitor session on the control plane to see if there's something odd going on.

j.

________________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Mayers [p.mayers at imperial.ac.uk]
Sent: Friday, November 13, 2009 5:18
To: Tim Durack
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] C6K, SUP720, 12.2(33)SXI, CoPP, glean

Tim Durack wrote:
> Anyone know how glean traffic behaves on a Sup720 with CoPP configured?

Glean traffic is matched against CoPP. This is "by design" according to
the (fairly clued up sounding) TAC engineer I spoke to.

As you've discovered, this is irritating.

>
> We have gradually locked down our CoPP config, to the point that our
> final class is a default deny for any unclassified traffic.
> Unfortunately this has the unwanted side-effect of dropping glean
> traffic, with the knock-on effect of some arp resolution problems.
>
> In our tests, it appears that configuring an explicit class-default
> works around this, but I can't find any documentation. So far TAC
> hasn't come up with anything either.

Really? Hmm. So you have a config where glean traffic is *not* being
matched by CoPP? Can you share the exact config?

I will unicast you the SR# of my case; perhaps the TAC engineers can
collude to produce a response clarifying.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/