Did you find anything else in the meanwhile ? What you found is potentially catastrophic...
Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) [email protected] http://www.ccie18473.net -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Robert Williams Sent: domingo, 4 de Maio de 2014 17:20 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/
