[c-nsp] Sup720 CoPP, limits on CPU performance

[Chris Griffin]

Anything matching a fixed mls rate limit will bypass copp, which can be 
a useful technique to avoid having to account for glean traffic in your 
copp policies.  Be cautious however, you may get this error message 
(only on the console!) when enabling:

%Packets requiring ARP resolution will be subject to the output ACLs of 
the input VLAN

This basically results in all the glean traffic being subject to 
non-obvious ACL behavior.  This is apparently a limitation in some 
versions of the PFC 3B, but has been fixed in the 3C.  Funny thing is 
that in our experiments not all of our PFC3Bs do it, but based on the 
fact that we could be required to replace one with a version that does 
have this limitation, we elected to avoid using it.

Tnx
Chris

On 3/23/2010 4:09 AM, Saku Ytti wrote:
> On (2010-03-22 22:23 -0400), Tim Durack wrote:
>
>> Not being able to differntiate receive from glean traffic is a huge
>> problem. This makes it difficult/impossible to permit approved control
>> plane traffic, then deny everything else. If you do, glean traffic
>> won't hit the control plane, causing arp failures. Not fun.
>
> I thought of Phil's email last night at bed, and concluded he must be right
> and I must be wrong, it made whole lot of sense and I was confused why I
> have not gotten into trouble because of it.
> Now I tried to reproduce the problem by taking ssh to IP address in my LAN
> where I don't have server.
> I see the 7600 sending arp who has to me, while CoPP does not allow the
> packet.
>
> RBUS result:
> CCC                              [3] = b101 [L2_POLICE]
> DEST_INDEX                       [19] = 0x7F05
> VLAN                             [12] = 4055
> RBH                              [3] = b111
>
> (4055 is vrf_0_vlan)
>
> If I try SSH to the router I get (CoPP drop):
> CCC                              [3] = b101 [L2_POLICE]
> DEST_INDEX                       [19] = 0x7FFF
> VLAN                             [12] = 4055
> RBH                              [3] = b010
>
> I remember by heart that 0x7FFF LTL is drop adjacency for various things
> (you can rewrite it to physical port, if you want to get CoPP drops out in
> analyser)
>
> 0x7F05 appears to be:
>   0x0465:            RED_RATE_IDX_4 = 0x00007F05 [32517     ]
>
> Which is again different from CoPP permit LTL. So glean appears in my
> 7600's to get its own adjacency, which as far as I can see in my case does
> not get evaluated by software CoPP.
> Not sure if this is side effect of one of these, or what. But could someone
> try to reproduce my results, since what you and Phil are saying makes
> perfect sense but I'm just not seeing the drops.
>
> mls qos protocol ARP police 2000000 62000
> mls rate-limit unicast cef glean 200 50
>
>
>> According to N7K docs, this is all fixed in EARL8...
>
>

-- 
Chris Griffin                           cgriffin at ufl.edu
Sr. Network Engineer - CCNP             Phone: (352) 273-1051
CNS - Network Services                  Fax:   (352) 392-9440
University of Florida/FLR               Gainesville, FL 32611