[c-nsp] BFD bypassing CoPP on 6500

[Mack McBride]

You didn't mention which line card models you were using and if dfcs are installed.
One disadvantage of CoPP on the sup720 family is that it is dependent on the incoming
line cards to rate limit in hardware.  Once it hits the RP it is handled in software.
So if the traffic is coming in multiple ports, each port will rate limit to the specified
value independently.  If you have x ports and your rate limit is y, you are actually open
to x*y traffic.  I haven't had a chance to play with the sup2T family but my understanding
is this was fixed in the sup2T.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbride at viawest.com | www.viawest.com | LinkedIn | Twitter | YouTube


-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Robert Williams
Sent: Sunday, May 04, 2014 10:20 AM
To: 'cisco-nsp at puck.nether.net'
Subject: [c-nsp] BFD bypassing CoPP on 6500

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
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/