Imagine your router is a bank, and the CPU is the vault. Control Plane Policing (CoPP) is the security guard who decides which people (packets) get to talk to the vault teller (CPU). Without CoPP, a flood of garbage packets could overwhelm the CPU, causing routing protocol hellos to be dropped and the network to collapse. On the CCNA 200-301 exam (objective 5.2), you need to understand how CoPP protects the control plane by rate-limiting traffic destined to the router itself, not just forwarding traffic through it. This is a high-stakes topic because misconfiguration can lock you out of your own router.
Jump to a section
Think of your router’s control plane as a VIP party inside a nightclub. The CPU is the celebrity host who can only talk to a few people at a time. Packets are partygoers trying to get the host’s attention. The data plane is the general dance floor – most packets just pass through without bothering the host. But some packets (like SSH, SNMP, routing protocol updates) need to talk directly to the host. Without a bouncer, a mob of rowdy guests could swarm the host, preventing the VIPs (OSPF hellos, BGP keepalives) from getting through. The club would lose its VIPs, and the party dies.
CoPP is that bouncer. The bouncer has a list of rules: VIPs (critical control traffic) get immediate access, but limited to a certain rate. Regular guests (management traffic like SSH) get a slower lane. Spammy guests (like ICMP flood) are turned away entirely if they exceed the limit. The bouncer uses a token bucket – each guest needs a token to get in. Tokens are replenished at a steady rate. If the bucket is empty, the guest is denied entry. This is exactly how CoPP works: it applies a QoS policy to packets destined to the control plane, using a class map to match traffic and a police action to rate-limit or drop. The bouncer doesn’t stop everyone – just those who abuse the privilege. And if the bouncer is too strict (e.g., blocking all SSH), even the club owner (network admin) can’t get in. That’s why careful planning is critical.
What is Control Plane Policing?
Control Plane Policing (CoPP) is a security feature on Cisco IOS/IOS-XE devices that protects the route processor (CPU) from being overwhelmed by excessive traffic destined to the router itself. The control plane is where routing protocols, management protocols (SSH, SNMP), and network control processes run. If the CPU gets too busy processing low-priority or malicious packets, it may fail to process critical control packets, leading to routing flaps, loss of management access, or even a complete outage.
CoPP allows you to define QoS policies that rate-limit traffic destined to the control plane. It works by intercepting packets before they reach the control plane and applying a policing action (transmit, drop, or mark down). This is different from interface-based QoS, which applies to traffic transiting the router. CoPP is a control-plane-specific security mechanism.
How CoPP Works at the Packet Level
When a packet arrives at a router interface, it goes through the data plane forwarding process. If the packet is destined for the router itself (e.g., destination IP is one of the router’s interfaces), it is punted to the control plane for processing. Before reaching the control plane, the packet is evaluated against the CoPP policy. The policy consists of:
Class maps – match traffic based on ACLs, protocol types, or QoS markings.
Policy map – associates class maps with actions (police, drop, set QoS markings).
Service policy – applied to the control plane under control-plane configuration mode.
Cisco Express Forwarding (CEF) punts packets to the control plane via a dedicated queue. CoPP applies to the aggregate control plane traffic, not per-interface. The policing uses a token bucket algorithm: tokens are added at a configured rate (e.g., 100,000 bits per second) up to a burst size. Each packet consumes tokens equal to its size. If enough tokens are available, the packet is transmitted; otherwise, it is dropped or marked down (e.g., set DSCP to 0).
CoPP Configuration Components
access-list: Defines which traffic to match (e.g., permit tcp host 10.1.1.1 host 10.1.1.2 eq 22).
class-map: Matches traffic based on ACL or other criteria. Example:
class-map match-all COPP-MGMT
match access-group 100policy-map: Defines police actions. Example:
policy-map COPP-POLICY
class COPP-MGMT
police 100000 20000 conform-action transmit exceed-action dropThe police command syntax: police <rate in bps> <burst in bytes> conform-action <action> exceed-action <action>.
- control-plane: Enters control plane configuration mode.
- service-policy: Applies the policy. service-policy input COPP-POLICY
Default Behavior and Timers
There is no default CoPP policy. By default, all control plane traffic is processed without rate-limiting. If you apply a policy, you must explicitly define classes for critical traffic (e.g., routing protocols) to ensure they are not dropped. A common mistake is to apply a restrictive policy that drops all traffic not explicitly permitted, which can lock out the administrator.
Verification Commands
To verify CoPP operation:
show policy-map control-plane inputSample output:
Control Plane
Service-policy input: COPP-POLICY
Class-map: COPP-MGMT (match-all)
1000 packets, 500000 bytes
5 minute offered rate 10000 bps, drop rate 2000 bps
Match: access-group 100
police:
cir 100000 bps, bc 20000 bytes
conformed 800 packets, 400000 bytes; actions: transmit
exceeded 200 packets, 100000 bytes; actions: drop
conformed 8000 bps, exceed 2000 bps
Class-map: class-default (match-any)
500 packets, 250000 bytes
5 minute offered rate 5000 bps, drop rate 0 bps
Match: anyAlso useful:
show control-plane host open-ports
show ip interface | include control-planeInteraction with Related Protocols
CoPP interacts with: - Control Plane Protection (CPPr): An advanced version that allows per-subinterface (e.g., management, host, transit) policies. CoPP is the simpler, more common implementation. - QoS: CoPP uses MQC (Modular QoS CLI) just like interface QoS. - ACLs: Used to classify traffic for CoPP. - Routing protocols: OSPF, EIGRP, BGP hellos are critical; they must be permitted in a high-priority class with adequate rate. - Management protocols: SSH, SNMP, NTP – should have moderate rate limits. - ICMP: Often rate-limited aggressively to prevent DoS.
Identify control plane traffic types
Before configuring CoPP, you must know what traffic is destined to the router. Common types: routing protocol packets (OSPF uses IP protocol 89, EIGRP uses 88, BGP uses TCP port 179), management traffic (SSH TCP 22, SNMP UDP 161, NTP UDP 123), and ICMP (echo, unreachable). Use `show control-plane host open-ports` to see listening services. Also use `debug ip packet` carefully in a lab to see punted packets. Document the source/destination IPs and protocols.
Create ACLs to match traffic
Define extended ACLs that permit the traffic you want to classify. For example, to match SSH from a management station (10.1.1.0/24): ``` access-list 100 permit tcp 10.1.1.0 0.0.0.255 host 10.1.1.2 eq 22 ``` For OSPF: ``` access-list 101 permit ospf any any ``` Use multiple ACLs for different classes. Remember that CoPP applies to traffic destined to any router interface IP, so use 'any' for the destination carefully.
Create class maps
Class maps group ACLs into categories. Use `match-all` (all conditions must match) or `match-any` (any condition). Example: ``` class-map match-all COPP-OSPF match access-group 101 ``` Create separate class maps for critical, normal, and undesirable traffic. Typically you have: CRITICAL (routing), MANAGEMENT (SSH/SNMP), ICMP, and DEFAULT (catch-all).
Create policy map with police actions
The policy map ties class maps to actions. For critical traffic, use a high rate or even 'police 10000000 2000000 conform-action transmit' (10 Mbps) – essentially no limit. For management, use a moderate rate (e.g., 1 Mbps). For ICMP, use a low rate (e.g., 64 kbps). For default, use a very low rate or drop. Example: ``` policy-map COPP-POLICY class COPP-CRITICAL police 10000000 2000000 conform-action transmit exceed-action transmit class COPP-MGMT police 1000000 200000 conform-action transmit exceed-action drop class COPP-ICMP police 64000 16000 conform-action transmit exceed-action drop class class-default police 32000 8000 conform-action transmit exceed-action drop ``` Note: The 'exceed-action transmit' for critical ensures no drops even if bursts exceed rate.
Apply the policy to the control plane
Enter control plane configuration mode and apply the policy as input: ``` control-plane service-policy input COPP-POLICY ``` The policy is now active. All traffic to the control plane is evaluated. Be careful: if you misconfigure, you could drop your own SSH session. Always test with a console connection or a scheduled reload.
Verify CoPP operation
Use `show policy-map control-plane input` to see packet counts, conformed/exceeded rates. Check that critical traffic has zero drops. If drops appear, adjust rates. Also use `show control-plane host open-ports` to ensure services are still listening. For troubleshooting, use `debug control-plane policy` (use with caution in production). Example verification: ``` Router# show policy-map control-plane input Control Plane Service-policy input: COPP-POLICY Class-map: COPP-CRITICAL (match-all) 500 packets, 25000 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: access-group 101 police: cir 10000000 bps, bc 2000000 bytes conformed 500 packets, 25000 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: transmit ```
In enterprise networks, CoPP is a first line of defense against control plane DoS attacks. A common scenario is an ISP edge router that receives BGP updates, OSPF hellos, and customer management traffic. Without CoPP, a customer sending a flood of ICMP echo requests to the router’s interface IP could starve the CPU, causing BGP hold timers to expire and routes to be withdrawn. The network engineer would configure CoPP with a high-priority class for BGP (TCP 179 from known peers), a medium class for OSPF (IP 89), and a low-rate class for ICMP. The default class would drop all other traffic. This ensures that even under attack, routing stability is maintained.
Another scenario is a data center switch acting as a default gateway. The CPU handles ARP, VRRP hellos, and SNMP polls. An ARP storm from a misconfigured host could overwhelm the CPU. CoPP can rate-limit ARP (using a class matching ARP – note that ARP is not IP, so you need a special class-map match protocol arp). The engineer sets a policer of 1000 pps for ARP. If the rate exceeds, packets are dropped, protecting the CPU while still allowing legitimate ARP.
A third scenario: remote access VPN concentrator. The router receives IPsec packets, SSH, and IKE. CoPP can protect the IKE control plane (UDP 500/4500) with a high rate, SSH with moderate rate, and drop all other traffic. Misconfiguration here can be catastrophic: if you accidentally drop IKE, VPN tunnels will not establish. Always test CoPP in a maintenance window with a backup console connection. Scale considerations: CoPP uses CPU resources for classification and policing; on high-end routers, hardware offload may be available. On low-end, heavy CoPP can itself become a CPU burden. Monitor CPU utilization after deployment.
What happens when misconfigured? The most common error is applying a policy that drops all traffic not explicitly permitted, but forgetting to permit critical protocols. The router will lose OSPF adjacencies, BGP sessions, and SSH access. The only recovery is through console or a scheduled reload with no service-policy in the startup config. That’s why many engineers first deploy with a 'permit all' default class and gradually restrict.
The CCNA 200-301 exam objective 5.2 (Security Fundamentals) includes CoPP as a control plane protection mechanism. You won’t be asked to configure CoPP from scratch, but you must understand its purpose, how it works, and how to interpret show commands. Expect scenario questions where a router is experiencing high CPU due to control plane traffic, and you need to recommend CoPP.
Common wrong answers: 1. Applying CoPP to interfaces – CoPP is applied to the control plane, not interfaces. Candidates confuse it with interface ACLs or QoS. 2. Using CoPP to filter transit traffic – CoPP only affects traffic destined to the router, not traffic passing through. For transit traffic, use interface ACLs. 3. Thinking CoPP is enabled by default – It is not. You must configure it. 4. Assuming police rate is in packets per second – Cisco police rate is in bits per second (bps), with burst in bytes. Candidates might misinterpret output.
Key values: The police command syntax is police <bps> <burst> conform-action <action> exceed-action <action>. Common actions: transmit, drop, set-dscp-transmit. The show policy-map control-plane input command shows conformed/exceeded packets and rates.
Calculation traps: None specific, but you might need to estimate required rates. For example, if OSPF sends a hello every 10 seconds (default) of 64 bytes, that’s negligible. But if many neighbors, scale up.
Decision rule: If the question says "traffic destined to the router" and "protect CPU", think CoPP. If the question says "traffic passing through the router", think ACL or interface QoS. If the question involves "management plane" or "routing protocol protection", CoPP is the answer.
CoPP protects the route processor (CPU) by rate-limiting traffic destined to the control plane.
CoPP uses MQC: class maps match traffic (via ACLs), policy maps define police actions, applied under 'control-plane' with 'service-policy input'.
The police command syntax: police <rate in bps> <burst in bytes> conform-action <action> exceed-action <action>.
Verify with 'show policy-map control-plane input' – look at conformed/exceeded packet counts.
Critical traffic (routing protocols) should have a high or unlimited police rate to avoid drops.
CoPP is not enabled by default; misconfiguration can lock you out – always test with console access.
CoPP applies only to traffic destined to the router, not transit traffic.
These come up on the exam all the time. Here's how to tell them apart.
CoPP (Control Plane Policing)
Applies to traffic destined to the router's control plane.
Uses MQC (class-map, policy-map) under 'control-plane'.
Can rate-limit (police) traffic based on class.
Protects CPU from overload.
Single policy for all interfaces.
Interface ACL
Applies to all traffic entering or leaving an interface.
Uses access-list applied with 'ip access-group' on interface.
Only permit/deny; no rate-limiting.
Protects interface from unwanted traffic.
Per-interface policy.
Mistake
CoPP can filter transit traffic.
Correct
CoPP only applies to traffic destined to the router's control plane (e.g., routing updates, management). Transit traffic is handled by the data plane and interface ACLs.
Candidates confuse control plane with data plane because both involve packets entering the router.
Mistake
CoPP is enabled by default on all interfaces.
Correct
CoPP is not enabled by default. It must be explicitly configured using the 'control-plane' command and 'service-policy input'.
Many security features like 'ip verify unicast source reachable-via' are not default; candidates assume similar protection exists.
Mistake
The police rate in CoPP is in packets per second (pps).
Correct
The police rate is in bits per second (bps). The burst size is in bytes. For example, 'police 100000 20000' means 100 kbps with 20,000 byte burst.
QoS police on interfaces uses bps; but some other rate limiters (like 'rate-limit' in older IOS) use pps, causing confusion.
Mistake
CoPP can be applied to individual interfaces.
Correct
CoPP is applied globally to the control plane. For per-interface control plane protection, use Control Plane Protection (CPPr) with per-subinterface policies.
Cisco has multiple control plane protection features; CCNA only covers CoPP, not CPPr.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CoPP (Control Plane Policing) applies a single QoS policy to all control plane traffic. CPPr (Control Plane Protection) allows separate policies for three subinterfaces: host (traffic from hosts), transit (traffic from routers), and CEF-exception (traffic that triggers special handling). CPPr is more granular but more complex. For CCNA, only CoPP is covered.
Yes, by using ACLs in the class map. For example, you can create an ACL that permits traffic from a specific source IP and then apply a police action of 'drop' in the policy map. However, for simple blocking, an interface ACL is easier. CoPP is primarily for rate-limiting, not just blocking.
There is no default CoPP policy. All control plane traffic is processed without any rate-limiting. You must configure CoPP explicitly. This is a common exam point: CoPP is not enabled by default.
Always have a console connection or a scheduled reload. Start with a permissive policy that permits all traffic (class-default with 'police 10000000 2000000 conform-action transmit exceed-action transmit') and then gradually restrict. Use 'reload in 10' before applying a restrictive policy so that if you lose access, the router reloads and reverts to the previous config.
Yes, CoPP applies to all traffic that is punted to the control plane, including process-switched traffic. However, most modern routers use CEF, and only traffic destined to the router is punted. CoPP works at the control plane entry point, after the packet has been identified as control plane traffic.
Yes, CoPP supports IPv6. You can use IPv6 ACLs in class maps to match IPv6 traffic (e.g., OSPFv3, ICMPv6). The same MQC syntax applies. For example: 'access-list ipv6 COPP-OSPFv3 permit ospf any any'.
The police command uses a token bucket. 'conform-action' is taken when the packet size is within the token bucket (i.e., rate is not exceeded). 'exceed-action' is taken when the packet exceeds the bucket (i.e., rate is exceeded). So 'conform-action transmit' means forward packets that are within rate; 'exceed-action drop' means drop packets that exceed the rate. This is how rate-limiting is achieved.
You've just covered Control Plane Policing (CoPP) — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?