[c-nsp] CoPP not catching software-switched CEF

[Saku Ytti]

On (2007-12-18 15:57 +0100), Blake Willis wrote:

Hello Blake,

> suffering-bxl#proc
> CPU utilization for five seconds: 46%/31%; one minute: 48%; five minutes: 48%

How much is the 31% above baseline? If your baseline is above 0%, only
mystery from my point of view we need to figure out is why you are
software switching.

> So normally any punted traffic that doesn't hit an MLS RL is picked up by CoPP, right?

This is my understanding also, which is kinda annoying and unexpected.

> ip access-list extended critical-protocols
>   deny <bunch of core protocols>
>   permit ip any any
> class-map match-all copp-ip
>    match access-group name critical-protocols

match-all is not supported. Do you run same CoPP config, in the previous
non-affected PFC3x box?

> This traffic doesn't hit the CoPP ACL (although IP proto 0 is "ip any any"):

Could you also verify:
show vlan internal  usage | i Control Plane Protection
remote command switch show tcam interface vlan ABOVE_VLAN_HERE qos type2 ip 

to see that CoPP is programmed in hardware.

>  	So, it seems that CoPP doesn't catch software-switched CEF (netint) 
> traffic as it apparently isn't punted to the MSFC via the EOBC.  I suppose a 
> workaround could be to apply a CoPP-like policy to every interface on the box 
> using CAR ("rate-limit input access-group...") as that would likely catch it 
> just as soft-switched netflow does, but that's fairly logistically annoying.

I think it does, but personally, I don't care if it does or if it does
not, since if you're software switching in MSFC3 you're dead with
or without CoPP, if you are not dead, buy cheaper faster software switching
box. So at this time, be be more interested to find out, why it was
software switched.

Perhaps 'sh mls cef lookup X detail', 'show mls cef adjacency entry X
detail' could help, adjacency is the 'A:n'. 

Thanks,
-- 
  ++ytti