[c-nsp] BFD bypassing CoPP on 6500

[Robert Williams]

Hi,

I can’t seem to find any relevant documentation on this so I’m hoping someone may know. I’ve identified that BFD traffic appears to bypass the CoPP in some respects (platform is 6500/Sup720/15.1SY).

The relevant test config is:

class-map match-any CoPP-bfd
  match access-group name V4-CoPP-bfd

ip access-list extended V4-CoPP-bfd
permit udp 10.10.0.0 0.0.255.255 gt 49151 any eq 3784
permit udp 10.10.0.0 0.0.255.255 gt 49151 any eq 3785

<within control-plane policy>
  class CoPP-bfd
   police 32000 100000 100000   conform-action transmit   exceed-action drop

So for example, if you send 50mbit/s of BFD traffic to it, then the output of “show policy-map control-plane input class CoPP-bfd” correctly shows that there is 50mbit/s of traffic being matched (in hardware) and that only 32,000bps of it is being forwarded. All looks fine, however, the CPU grinds to a halt, even though the exceed-action is set to ‘drop’ so nothing more than a tiny 32,000 should get through. I’ve confirmed it is indeed all getting through as you can see it in a CPU span session.

Also, the class-default in the control-plane policy is set to conform-action drop as well. So how is it even getting through?

Interestingly, if you set the conform-action to drop on class CoPP-bfd then it still hits 100% CPU. Although strangely if you _do_ set CoPP-bfd to conform-drop then also the genuine BFD ‘real’ sessions suddenly stop working. So the ‘drop’ feature does have some impact still, somehow…

This is in a lab setup with little else running on the boxes and I’m able to test anything if anyone has any ideas why this is occurring.

#remote command switch show tcam interface vlan 1013 qos type2 ip

* Global Defaults shared

------------------------------------------------------
QOS Results:
A - Aggregate Policing       F - Microflow Policing
M - Mark                     T - Trust
U - Untrust
------------------------------------------------------
    MAU    udp 10.10.0.0 0.0.255.255 gt 49151 any eq 3784
    MAU    udp 10.10.0.0 0.0.255.255 gt 49151 any eq 3785


#remote command switch show tcam interface vlan 1013 qos type2 ip detail

Interface: 1013   label: 3   lookup_type: 2
protocol: IP   packet-type: 0

+-+-----+---------------+---------------+---------------+---------------+-------+---+----+-+---+--+---+---+
|T|Index|  Dest Ip Addr | Source Ip Addr|     DPort     |     SPort     | TCP-F |Pro|MRFM|X|TOS|TN|COD|F-P|
+-+-----+---------------+---------------+---------------+---------------+-------+---+----+-+---+--+---+---+
V 35925         0.0.0.0       10.10.0.0       P=3784          P>49151    ------  17 ---- 1   0 -- --- 0-0  <-
M 35927         0.0.0.0     255.255.0.0         65535                    ------ 255 --X- 1   0             <-
R rslt: 503           <-

V 35926         0.0.0.0       10.10.0.0       P=3785          P>49151    ------  17 ---- 1   0 -- --- 0-0  <-
M 35927         0.0.0.0     255.255.0.0         65535                    ------ 255 --X- 1   0             <-
R rslt: 503           <-


Since it’s just UDP on a certain port I don’t see how/why this would be treated any differently from any other type of traffic going to the CPU. I know there are various restrictions and limitations (like ARP, IP Options etc.) but this is nothing ‘special’ – just UDP traffic - or at least I thought so?

So what am I missing here? Cheers!

Robert Williams
Custodian Data Centre
Email: Robert at CustodianDC.com
http://www.CustodianDC.com