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

[Phil Mayers]

I'm a bit confused about what you're trying to say here. The mls glean rate limiter is completley different to copp. The op's problem, and one i have observed too, is that copp is applied to all cpu traffic, including the original packet which was punted to glean.

IMHO, and tac have advised me of the same, enabling the mls glean limiter is second only to enabling the receive limiter in terms of risk. It's not useful in the general case, because it's not source- or svi-specific.

In short - copp is a good, source specific tool to control received packets, but the issue under discussion is that, on 6500, it applies to packets that trigger glean too, which is usually unhelpful. It's definitely unhelpful if you want to put a 0.0.0.0/0 destination in your copp acls.

-original message-
Subject: RE: [c-nsp] C6K, SUP720, 12.2(33)SXI, CoPP, glean
From: "John.Herbert at ins.com" <John.Herbert at ins.com>
Date: 14/11/2009 15:25


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/