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

[Saku Ytti]

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...


-- 
  ++ytti