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

[Saku Ytti]

On (2007-12-18 22:51 +0100), Blake Willis wrote:

Hi Blake,

> Baseline is usually around 5% or less.  The vast majority of it is 
> usually IPSec AH, which I can understand why the PFC can't forward & needs to 

Is the IPSec being terminated to the box itself? If it's just passing
through, it shouldn't be visible in CPU I/O load. Unless of course you
have IP Options there also, but you already had MLS rate-limit for them,
so they can't explain software switching either.
How many packets are you pushing through this system?
(show platform hardware capacity pfc | b Forwarding engine load)

> > match-all is not supported.
> 
>  	The config is loaded "class-map copp-ip" and the "match-all" is added by 
> the mucular QoS conflaguraterator by itsself.  The docs (and most other examples 
> I've seen) seem to use "match-all".  In general the CoPP filter in place has 
> usefully blocked plenty of other stuff in the past (mostly ICMP & UDP floods) 
> while preserving protocol traffic as normal:

I would refine it as 'class-map match-any copp-ip'. Of course you appear
only to have one rule there, so I'm not sure if there any problem there. But I
know CoPP doesn't support match-all. I wish it did, because then I could do
stuff like this:
class-match match-all CoPP-ALLOW_BGP_FROM_CORE
  match access-group name CORELOOPS
  match access-group name BGP
class-match match-all CoPP-ALLWO_LDP_FROM_CORE
  match access-group name CORELOOPS
  match access-group name LDP
!

Now, as this is not supported, if I want exactly same effect, I need to
maintain CORELOOPS_BGP, CORELOOP_LDP etc ACL's with mostly duplicate info.

> remote command switch show tcam interface vlan <CoPP vlan> qos type2 ip                                
Thanks, that's really useful.  The CoPP policy is loaded properly.                                       

What did it read before your 'copp-ip' rule list. Were they all 'MAU' and
then you had one final line with 'AT'?

> suffering-bxl-sp#show qm-sp index2label | incl 4087
>  	Be careful with the qm-sp stuff though, the output is not paginated so 
> you can sit there for a while waiting for it to go by...  It's too bad one can't 
> see something like "show qm-sp port-data" for the EOBC/IBC or CoPP as it's 
> really nice to be able to actually see the buffer sizes on physical ports.

Interesting, thanks.

>  	BTW, after digging up the "7600 cheat-sheet" from the archives, the 
> answer is that soft-switched CEF is punted to the MSFC via the IBC interface, 
> and CoPP seems to be applied to the EOBC:

Yes, I think EOBC is really for pushing stuff like forwarding tables
to DFC. Taking terminal session to linecard etc. I'm not sure why
CoPP would live there though, but as for previously stated reason,
I'm not very interested on how CoPP works in software path.
I'd be interested getting your cheat sheet though :)


> suffering-bxl#sh ibc | incl rate
>          5 minute rx rate 2082000 bits/sec, 2356 packets/sec
>          5 minute tx rate 4400000 bits/sec, 2473 packets/sec

This is really high software switching baseline in my opinion. 

> > 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,
> 
>  	Shouldn't CoPP limit punts from the PFC before they hit the CPU? 
> Obviously, for software-switched CEF punted via the IBC, it doesn't.

Definitely, and it is indeed my experience too, that even transit
packets hit CoPP, if they are punted. And what happens after they
are punted, in software path, I couldn't really care less. My guess
is that you're software switching and for some reason CoPP isn't working
correctly, hopefully it's just because of 'match-all'
Do you run ACL's in the interfaces where traffic was ingressing
or egressing?
 
>  	Only this one flow was soft-switched so it's likely not resource 
> exhaustion, especially as we make very light usage of acl/qos tcam on core 
> boxes.

But you have some base load for software switching all the time, so I think
it should be possible to find reason, why that is happening.

> suffering-bxl#sh mls cef adj entr 311314 det
> Index: 311314  smac: 00d0.0337.9c00, dmac: 0000.0910.0000
>                 mtu: 4488, vlan: 4060, dindex: 0x0, l3rw_vld: 1
>                 format: MAC_TCP, flags: 0x2000008408
>                 delta_seq: 0, delta_ack: 0
>                 packets: 3847042483, bytes: 733883009662

Is VLAN 4060 correctly the L3 interface you're egressing the DoS?

> suffering-bxl#sh mls cef adj special | incl 0x2000008408
>                 format: MAC_TCP, flags: 0x2000008408 (receive)

Are you sure this is ok? That you should actually have receive here?

> that gets forwarded in the netint path.  I think that the CAR solution is 
> looking like the answer...

I don't think that will be necessary, I'm pretty certain something
is wrong here, and key is finding out, what is causing your software
switching.

-- 
  ++ytti