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

[Tim Durack]

On Fri, Nov 13, 2009 at 5:18 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> 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.

Indeed. It makes no sense for glean traffic to be lumped in with
everything else destined to the control-plane. The only thing that
needs to happen with glean traffic is an arp request.

It looks like with the Nexus Cisco have improved/corrected this.
http://tinyurl.com/yc2c737 states:

Different types of packets can reach the control plane:

Receive packets
Packets that have the destination address of a router. The destination
address can be a Layer 2 address (such as a router MAC address) or a
Layer 3 address (such as the IP address of a router interface). These
packets include router updates and keepalive messages. Multicast
packets can also be in this category where packets are sent to
multicast addresses that are used by a router.
Exception packets
Packets that need special handling by the supervisor module. For
example, if a destination address is not present in the Forwarding
Information Base (FIB) and results in a miss, then the supervisor
module sends an ICMP unreachable packet back to the sender. Another
example is a packet with IP options set.
Redirected packets
Packets that are redirected to the supervisor module. Features like
Dynamic Host Configuration Protocol (DHCP) snooping or dynamic Address
Resolution Protocol (ARP) inspection redirect some packets to the
supervisor module.
Glean packets
If a Layer 2 MAC address for a destination IP address is not present
in the FIB, the supervisor module receives the packet and sends an ARP
request to the host.

...

Configuring a Control Plane Policy Map

You must configure a policy map for CoPP, which include policing
parameters. If you do not configure a policer for a class, then the
default policer conform action is drop. Glean packets are policed
using the default-class. The Cisco NX-OS software supports 1-rate
2-color and 2-rate 3-color policing.

>>
>> 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 think I was wrong. Still have the same problem.

> I will unicast you the SR# of my case; perhaps the TAC engineers can collude
> to produce a response clarifying.
>

Thanks, will take a look.

In my book, this behaviour undermines the value of copp. I can't
tightly restrict traffic to the control-plane, as glean traffic could
be anything.

-- 
Tim:>
Sent from Brooklyn, NY, United States