Hello,
I have a discussion with a customer that has made me question my own understanding of control plane policing.
They noticed that, although they could use copp in older IOS routers to restrict access to the inband management plane to a specific host or subset of hosts, they cannot do the same for the OOB intf of a more modern L3 switch, running IOSXE. On the same switch, it works fine on an inband mgmt SVI.
They are using a config template that looks like this:
a) Mgmt access via SVI
interface Vlan123
description mgmt SVI
ip address 1.2.3.4 255.255.255.0
access-list 121 remark COPP_MANAGEMENT
access-list 121 permit udp host 5.6.7.8 any
class-map match-all Management
match access-group 121
policy-map RTR_CoPP
[…]
class Management
police rate 1000000 bps burst 200000 bytes peak-burst 200000 bytes conform-action transmit exceed-action drop
[…]
class class-default
police rate 32000 bps burst 1500 bytes peak-burst 1500 bytes conform-action transmit exceed-action transmit
control-plane
service-policy input RTR_CoPP
------
b) Mgmt access via OOB
interface FastEthernet1
description Uplink to mgmt switch
vrf forwarding mgmtVrf
ip address 11.22.33.44 255.255.255.192
access-list 121 remark COPP_MANAGEMENT
//no ACE for source host 5.6.7.8 configured this time
class-map match-all Management
match access-group 121
policy-map RTR_CoPP
[…]
class Management
police rate 1000000 bps burst 200000 bytes peak-burst 200000 bytes conform-action transmit exceed-action drop
[…]
class class-default
police rate 32000 bps burst 1500 bytes peak-burst 1500 bytes conform-action transmit exceed-action transmit
control-plane
service-policy input RTR_CoPP
The are saying that although the first scenario works (meaning: only hosts in ACL 121, in this case only host 5.6.7.8, can reach the mgmt plane and udp traffic is policed to 1Mbps) the second scenario does not; because even in the absence of an ACL entry, host 5.6.7.8 can reach the device or send as much traffic volume as it wants - it is not policed.
Also, in the case of the SVI, if the host is removed from the ACL, it is completely blocked from accessing the device - making the difference between SVI and OOB even more apparent.
The relatively obvious explanation for this behavior is that OOB mgmt is exempt from CoPP, as stated in https://www.cisco.com/c/en/us/td/docs/ios/security/configuration/guide/sec_mgmt_plane_prot.html#wp1049319 under 'Restrictions'. Hence, trying to influence OOB traffic using CoPP is pointless, since the traffic is not punted to the control plane interface in the first place.
When confronted with this, they wondered how come that Cisco has not created a similar protection mechanism for OOB interfaces.
Looking at this config template, my first thought is that they have partly misunderstood what the feature is for - based on the classic example in here https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_plcshp/configuration/15-mt/qos-plcshp-15-mt-book/qos-plcshp-ctrl-pln-plc.html
the ACL deny entries are used to designate trusted networks, and all traffic coming from the networks or hosts under the permit entries is what is actually subject to policing. And, most importantly, that CoPP is not meant to deny access to some subset of hosts, but rather to police their traffic to prevent DoS attacks on the CPU.
But, what i don't understand is why, in their template, a host that is not in the ACL permit entries is blocked from accessing the SVI (this behavior is probably what led them to believe that CoPP can be used for access restriction). Is there some equivalent to implicit deny at work here? Why would a CoPP config, that does only policing and doesnt contain an explicit drop statement, deny a host from using a protocol?
Thanks a lot,
Filippos
