Lesson Contents
On our routers (or multilayer switches) we can use access-lists or firewalls (CBAC or zone based) to permit/deny packets that go through or to the router.
We can also use policing to rate limit that goes through our router.
What if we want to police traffic that is destined to the router? There are quite some protocols that produce packets that the router has to process:
- Routing protocols like OSPF, EIGRP, or BGP.
- Gateway redundancy protocols like HSRP, VRRP, or GLBP.
- Network management protocols like telnet, SSH, SNMP, or RADIUS.
- Packets that CEF can’t forward.
The route processor inspects packets that these protocols generate on the control plane. When the route processor receives too many packets, it’s possible that it can’t keep up and drops packets.
When this happens, you’ll see things like flapping neighbor adjacencies or timeouts when you try to connect with telnet/SSH to the router.
To prevent this from happening, we have a couple of options:
- rACLs (Receive Access Control List): these are standard or extended ACL that control traffic sent by line cards to the route processor. You only see this feature on high-end routers like the Cisco 12000 series.
- Control Plane Policing (CoPP): allows you to use MQC (Modular Quality of Service) framework to permit/deny or rate-limit traffic that goes to the route processor.
- Control Plane Protection (CPPr): this is an extension of CoPP. One of the things it does is separating the route processor into three sub-interfaces:
- host
- transit
- CEF exception
In this lesson, we’ll take a look at CoPP (Control Plane Policing).
Configuration
To demonstrate CoPP, I use the following topology:
Here’s what we have:
- R1 and R2 run OSPF and HSRP.
- R1 is configured for remote access through telnet.
- H1 is a host that generates ICMP and telnet traffic to test CoPP on R1.
Configurations
Want to take a look for yourself? Here you will find the startup configuration of each device.
H1
hostname H1
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.101 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end
R1
hostname R1
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
standby version 2
standby 1 ip 192.168.1.254
standby 1 priority 200
standby 1 preempt
!
router ospf 1
network 192.168.1.0 0.0.0.255 area 0
!
end
R2
hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.2 255.255.255.0
standby version 2
standby 1 ip 192.168.1.254
standby 1 preempt
!
router ospf 1
network 192.168.1.0 0.0.0.255 area 0
!
end
Control plane policing uses the MQC so that means we have to use class-maps and a policy-map. In your class-maps, it’s best to match traffic on:
- standard or extended access-lists
- DSCP or IP precedence values.
NBAR classification is not supported on all platforms and or IOS versions. The only exception to this rule is match protocol arp
Let’s create some access-lists that match traffic on the control plane that we can use in our class-maps:
R1(config)#ip access-list extended ICMP
R1(config-ext-nacl)#permit icmp any any
R1(config)#ip access-list extended TELNET
R1(config-ext-nacl)#permit tcp any any eq 23
R1(config)#ip access-list extended OSPF
R1(config-ext-nacl)#permit ospf any any
R1(config)#ip access-list extended HSRP
R1(config-ext-nacl)#permit udp any host 224.0.0.102 eq 1985
Let’s create class-maps that match the access-lists:
R1(config)#class-map ICMP
R1(config-cmap)#match access-group name ICMP
R1(config)#class-map TELNET
R1(config-cmap)#match access-group name TELNET
R1(config)#class-map OSPF
R1(config-cmap)#match access-group name OSPF
R1(config)#class-map HSRP
R1(config-cmap)#match access-group name HSRP
Now I can create a policy-map:
R1(config)#policy-map COPP
R1(config-pmap)#class ICMP
R1(config-pmap-c)#police 8000 conform-action transmit exceed-action transmit
R1(config-pmap-c)#exit
R1(config-pmap)#class TELNET
R1(config-pmap-c)#police 8000 conform-action transmit exceed-action transmit
R1(config-pmap-c)#exit
R1(config-pmap)#class OSPF
R1(config-pmap-c)#police 8000 conform-action transmit exceed-action transmit
R1(config-pmap-c)#exit
R1(config-pmap)#class HSRP
R1(config-pmap-c)#police 8000 conform-action transmit exceed-action transmit
R1(config-pmap-c)#exit
In the policy-map, I add policers for 8000 bps and the conform-action and exceed-action are both set to transmit. These policers will never drop anything but there is a good reason I configure it like this.
When you configure CoPP for the first time, you don’t know how much packets you receive for each protocol. There is a risk that you deny legitimate traffic. It’s best to permit everything. Once you know how much packets are exceeding, change the values and set the exceed action to drop.
We need to attach this policy-map to the control plane. We do this with the following command:
Hello
Interesting topic and good explanation.
From what I understand with control plane policing and protection we create a filter between the interface and the CPU to filter packets handled by the CPU of the router.
Correct me if i ’ m wrong but with your example
which is enabling policing for incoming traffic to the router, an incoming ssh packet for example to the router will not be dropped but will not be under inspection either .
Is this correct?
Thanks
Kostas
Hello Kostas
Yes, that is correct. We can filter the number of packets destined to the router itself, and thus, we limit the number of packets that the CPU must process. Keep in mind however that even data plane traffic uses CPU resources (for decapsulating, routing, re-encapsulating etc) as well.
In this lesson, Rene is matching control plane traffic for ICMP, Telnet, OSP
... Continue reading in our forumHello
Thank you for the explanation.
I was reading about CoPP and I read on a forum an example on why to use it.
It was mentioned that if for example you want to filter traffic to an outside interface with an access list , and someone manage to send a lot of traffic to that interface , even though the traffic will be dropped as it matches the drop action in the access list ,this will have an impact on CPU .
On the other hand with CoPP you will have a silent drop meaning packets will never reach CPU .
In this example applying an access list to an interface for t
... Continue reading in our forumGeia sou (hello) Kostas
This is a very important aspect that you bring up. There are several things that come into play.
Under normal operation, a networking device that receives control plane traffic will “punt” the packet to the CPU to be processed. The term “punt” is used to describe the action of moving a packet from the fast path to the route processor or CPU for handling. CoPP will block the packet from even reaching the CPU therefore there is no impact on the CPU itself. Take a look at the following diagram taken from this Cisco Documentation:
//cdn-
... Continue reading in our forumThank you so much for your response.
The documentation really helped me a lot as well.
kostas