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/
