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 | [email protected] | www.viawest.com | LinkedIn | Twitter | YouTube -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Robert Williams Sent: Sunday, May 04, 2014 10:20 AM To: '[email protected]' 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: [email protected] http://www.CustodianDC.com _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
