Sign in Subscribe

CoPP for CCNP ENCOR: How Control Plane Policing Protects Cisco Device CPUs

CoPP for CCNP ENCOR: How Control Plane Policing Protects Cisco Device CPUs

1. Introduction: What CoPP Is and Why It Matters

Control Plane Policing (CoPP) protects the device CPU by rate-limiting traffic that reaches the control plane. For CCNP ENCOR, the core idea is simple but easy to misapply: CoPP is for CPU-bound or punted traffic, not ordinary hardware-forwarded transit traffic. If packets stay in the data plane and are switched in hardware, CoPP is usually not involved. If packets are destined to the router itself or are punted to the CPU because they require software handling, CoPP becomes relevant.

That distinction matters in production. A router can still forward normal user traffic at full speed and, at the same time, have its CPU getting hammered by routing updates, management logins, ICMP storms, ARP or ND chatter, malformed packets, or other exception traffic. That’s the sneaky part: the data plane can look totally fine while the control plane is getting hammered in the background. And when that starts happening, you’ll see neighbors flapping, SSH sessions getting unreliable, SNMP polls timing out, and the box acting like it’s only half alive — even though transit forwarding still looks perfectly healthy. CoPP exists to keep CPU resources usable under both normal bursts and abusive conditions.

For ENCOR, remember this definition: CoPP controls traffic to the control plane so legitimate protocol and management traffic can continue without overwhelming the CPU.

2. Data Plane, Control Plane, Management Plane, and the Punt Path

The data plane is the forwarding path. On modern Cisco platforms, most transit traffic is switched in hardware by ASICs or forwarding engines. The control plane is where the device runs routing protocols, protocol state machines, ARP/ND processing, and other CPU-based decisions. The management plane is how administrators and tools interact with the device: SSH, SNMP, AAA, NTP, NETCONF/RESTCONF, and similar services. In practice, management traffic is often protected with CoPP because it is also CPU-destined.

The missing concept many engineers need is the punt path. Traffic reaches the CPU in several ways:

  • It is destined to a local interface address on the device, such as SSH to a loopback or BGP to a routed interface.
  • It is control traffic the device must process, such as OSPF hellos or HSRP packets.
  • It is exception traffic that could not be fully handled in hardware, such as TTL expiry, MTU-related ICMP generation, ARP resolution, or platform-specific CEF exceptions.
  • It is malformed, unsupported, or otherwise requires software inspection.

That is why “CoPP does not protect transit traffic” needs one refinement: it does not police ordinary hardware-forwarded transit traffic, but it may affect transit packets that are punted to the CPU as exceptions. Exact behavior is platform-dependent.

3. What Traffic Should CoPP Protect?

CoPP should cover traffic that is destined to the device or otherwise punted for control-plane processing. In real networks, this traffic usually falls into a few familiar buckets:

  • Routing protocols: OSPF, EIGRP, BGP, RIP, OSPFv3, and sometimes BFD. IS-IS is definitely control-plane traffic too, but since it isn’t IP-based, matching it can get a bit more platform-specific than a basic IP ACL example might suggest.
  • First-hop redundancy protocols: HSRP (UDP/1985), GLBP (UDP/3222), and VRRP (IP protocol 112).
  • Management and services: SSH, SNMP, TACACS+, RADIUS, NTP, NETCONF/RESTCONF, and device-terminated syslog if used.
  • IPv6 essentials: ICMPv6 neighbor discovery, router solicitation/advertisement, packet-too-big, time-exceeded, and parameter-problem messages. If you over-police ICMPv6, you can absolutely break IPv6, and I’ve seen that bite people in production.
  • Exception and infrastructure traffic: ARP, DHCP relay-related traffic, and platform-specific punted packets.

Not all of this traffic is hostile. Honestly, a lot of this traffic isn’t optional at all—it’s required just for the device to function normally. A bad CoPP design usually goes one of two directions: it’s so loose that it doesn’t really protect anything, or it’s so tight that it starts breaking routing, FHRP, IPv6 neighbor discovery, or management access. And yeah, that second one gets ugly fast.

Best practice is to treat CoPP as the last line of CPU protection, not the first security control. You want to block unwanted infrastructure-directed traffic as early as you can, using iACLs, interface ACLs, uRPF where it fits, and management-plane restrictions. Then use CoPP to ensure whatever still reaches the CPU does so at sustainable rates.

4. CoPP vs CPPr, MPP, ACLs, and QoS

CoPP is often confused with related features:

  • CoPP: rate-limits traffic to the control plane/CPU.
  • CPPr: Control Plane Protection, a more granular model on some IOS/IOS XE platforms that can separate host traffic, transit exception traffic, and CEF-exception traffic. It is related to CoPP, but not identical and not universal.
  • MPP: Management Plane Protection restricts which interfaces accept management protocols like SSH or SNMP. MPP is often a better answer when the goal is “only allow management on this interface,” while CoPP is the right answer when the goal is “protect the CPU from excessive management traffic.”
  • iACLs/interface ACLs: filter unwanted traffic before it reaches the box. These reduce attack volume earlier than CoPP.
  • QoS policing: also uses MQC, but usually applies to user traffic on interfaces, not the router CPU.

Exam trap: if the question says “protect the router CPU from excessive packets,” think CoPP. If it says “restrict SSH so it is accepted only on a specific interface,” think MPP or ACLs, depending on the options.

5. How CoPP Works with MQC and Why Policing Is Used

Classic IOS/IOS XE CoPP commonly uses MQC:

  1. Classify traffic, usually with ACLs
  2. Match that traffic in class maps
  3. Apply policers in a policy map
  4. Attach the policy under control-plane with service-policy input

Policing is used instead of shaping because the CPU is not a place where you want queues to build. Shaping delays traffic by buffering it; CoPP is meant to enforce a hard ceiling on how much work reaches the CPU. For ENCOR, that is the exam answer.

Under the hood, policers use token-bucket logic. The two values that matter most are CIR and BC. CIR is the sustained rate. BC is the burst size the policer can absorb before drops begin. This matters because routing and control traffic is often bursty. A policy with a reasonable average rate but an undersized burst parameter can still drop short hello or reconvergence bursts. Some platforms also support pps-based policing, which can be more meaningful for CPU protection because CPU stress often correlates better with packets per second than with bits per second.

6. Safer Classification Design

A good CoPP design separates traffic by operational importance and trust. A practical model is:

  • Routing/BFD: highest priority because loss here affects adjacency and convergence.
  • FHRP: important for gateway stability.
  • Management: allow only trusted sources and reasonable rates.
  • Diagnostics: ICMP and limited troubleshooting traffic.
  • Default/unknown: tightly policed, not blindly trusted.

Be careful with broad matches such as permit tcp any any eq 179. That may classify unintended traffic as critical. In production, match known peer addresses, loopbacks, or management subnets whenever possible. The same warning applies to SNMP, TACACS+, and SSH. CoPP is not just about rates; it is also about who is allowed into privileged classes.

7. Corrected IOS XE-Style CoPP Example

This is a compact lab example, not a universal production template. Syntax and supported match types vary by platform, and some devices already have system CoPP policies in place.

ip access-list extended COPP-ROUTING permit ospf any host 192.0.2.1 permit eigrp any host 192.0.2.1 permit tcp host 198.51.100.2 host 192.0.2.1 eq 179 permit udp host 198.51.100.3 host 192.0.2.1 eq 3784 ip access-list extended COPP-FHRP permit udp any host 224.0.0.2 eq 1985 ppermit udp any host 224.0.0.102 eq 3222 permit 112 any any ip access-list extended COPP-MGMT permit tcp host 10.10.10.10 host 192.0.2.1 eq 22 permit udp host 10.10.10.20 host 192.0.2.1 eq 161 permit tcp host 10.10.10.30 host 192.0.2.1 eq 49 permit udp host 10.10.10.40 host 192.0.2.1 eq 1812 permit udp host 10.10.10.50 host 192.0.2.1 eq 123 ip access-list extended COPP-ICMP permit icmp any host 192.0.2.1 ! ipv6 access-list COPP-IPV6-CTRL permit ospf any host 2001:db8:100::1 permit tcp host 2001:db8:200::2 host 2001:db8:100::1 eq 179 permit icmp any host 2001:db8:100::1 nd-na permit icmp any host 2001:db8:100::1 nd-ns permit icmp any host 2001:db8:100::1 router-solicitation permit icmp any host 2001:db8:100::1 router-advertisement permit icmp any host 2001:db8:100::1 packet-too-big permit icmp any host 2001:db8:100::1 time-exceeded permit icmp any host 2001:db8:100::1 parameter-problem permit icmp any host 2001:db8:100::1 echo-request ! class-map match-any CM-ROUTING match access-group name COPP-ROUTING class-map match-any CM-FHRP match access-group name COPP-FHRP class-map match-any CM-MGMT match access-group name COPP-MGMT class-map match-any CM-ICMP match access-group name COPP-ICMP class-map match-any CM-IPV6-CTRL match access-group name COPP-IPV6-CTRL ! policy-map PM-COPP class CM-ROUTING police 1000000 conform-action transmit exceed-action drop class CM-FHRP police 256000 conform-action transmit exceed-action drop class CM-MGMT police 256000 conform-action transmit exceed-action drop class CM-ICMP police 64000 conform-action transmit exceed-action drop class CM-IPV6-CTRL police 256000 conform-action transmit exceed-action drop class class-default police 32000 conform-action transmit exceed-action drop ! control-plane service-policy input PM-COPP

Here’s why this version is safer than the sort of example people tend to memorize without really thinking it through:

  • SNMP is correctly matched as UDP/161, not TCP.
  • TACACS+ is correctly matched as TCP/49.
  • VRRP is included as IP protocol 112.
  • Broad and misleading entries like UDP/33434 are removed.
  • BGP and management traffic are narrowed to trusted sources and local destinations instead of any any.
  • IPv6 ICMP is not treated as generic “ping only”; required ICMPv6 control types are explicitly considered.

ARP and IS-IS are intentionally not shown in this simple IP ACL example because their handling is more platform-specific than many study guides admit.

8. How to Choose Initial Policer Values

Do not copy sample rates blindly. A better method is:

  1. Inventory CPU-destined protocols by device role.
  2. Measure normal rates and failure-event bursts.
  3. Start permissive enough to avoid breakage.
  4. Observe counters and CPU trends.
  5. Tighten gradually.

A branch router with one OSPF neighbor and occasional SSH needs a very different profile from a campus distribution switch with many SVIs and HSRP groups, or an internet edge router with multiple BGP peers and route churn. If supported, pps-based policers are often useful for ICMP, routing hellos, and management traffic because packet volume, not bandwidth, is usually what hurts the CPU.

9. Verification and Diagnostics

Start with MQC counters, then move outward:

show policy-map control-plane show access-lists show class-map show processes cpu sorted show ip ospf neighbor show bgp summary

On some IOS XE platforms, add platform-specific commands that display punt statistics and hardware forwarding behavior. The commands for checking control-plane status or policy attachment can vary a little from platform to platform, so it’s really important to verify them on the actual device you’re working with.

When you’re checking the output, here’s where I’d start:

  • Zero matches in a class when the protocol is active usually means classification is wrong.
  • Exceed drops in a critical class during adjacency loss usually means over-policing.
  • Class-default drops increasing often means you missed an important protocol or trusted source.
  • High CPU with no CoPP drops suggests the issue may be process-related, unclassified, or not punt-path traffic at all.

10. Common CoPP Misconfigurations and Troubleshooting

The most common CoPP failures are predictable:

  • Wrong protocol match, such as SNMP over TCP instead of UDP
  • Overly broad matches that let untrusted traffic into critical classes
  • IPv4-only thinking in a dual-stack network
  • Missing trusted management source IPs
  • Replacing default/system CoPP without understanding platform baselines
  • Policer rates or burst sizes that are too small for convergence events

A fast troubleshooting workflow is:

  1. Check show policy-map control-plane for drops.
  2. Check ACL hit counts to confirm classification.
  3. Validate routing neighbors, FHRP state, SSH, and SNMP behavior.
  4. Check CPU processes and punt statistics.
  5. Adjust the specific class, not the whole policy, unless the design itself is wrong.

Example: if IPv6 hosts suddenly lose reachability after CoPP deployment, do not focus only on echo traffic. Look for over-policing of ND, router advertisements, or packet-too-big messages. IPv6 often fails in subtle ways when ICMPv6 is treated like optional diagnostics.

11. Default/System CoPP and Platform Behavior

This is where real deployments differ from lab guides. Many Cisco platforms ship with default or system-generated CoPP policies. Some are editable, some are partially visible, and some should be augmented rather than replaced. Always inspect the existing state before adding your own policy.

Platform behavior also differs in what gets punted, where classification occurs, and how host-bound versus transit-exception traffic is separated. IOS, IOS XE, Catalyst switching platforms, and NX-OS do not all behave identically. For ENCOR, favor the conceptual truth: CoPP protects the CPU/control plane. For production, validate syntax, defaults, punt behavior, and supported match types on the exact platform.

12. ENCOR Quick Facts and Exam Traps

Quick facts to memorize:

  • CoPP protects the CPU/control plane.
  • CoPP does not protect ordinary transit traffic.
  • CoPP commonly uses MQC.
  • Classic IOS/IOS XE CoPP is applied under control-plane with service-policy input.
  • Policing is preferred over shaping.
  • CPPr is related but more granular on some platforms.

Top exam traps:

  • Confusing CoPP with interface ACLs or QoS on transit traffic
  • Saying CoPP protects all traffic through the router
  • Choosing shaping instead of policing
  • Forgetting IPv6 control traffic, especially ICMPv6/ND
  • Treating CPPr as identical to CoPP everywhere
  • Assuming all CPU-bound traffic should be blocked instead of rate-limited

If a question says users still pass traffic but routing and SSH are unstable, that is a classic control-plane symptom and CoPP should be on your shortlist.

13. Conclusion

CoPP is one of the most practical infrastructure protection features in the ENCOR blueprint because it addresses a very real operational problem: the CPU is finite, shared, and easy to overwhelm with traffic that must be processed in software. The right mental model is actually pretty straightforward once you strip away the noise: figure out what legitimately needs CPU attention, classify it carefully, allow it at sustainable rates, and then police everything else tightly enough to protect the box without breaking the network.

If you remember the exam-ready version, remember this: CoPP protects the control plane, usually with MQC policing, and it is applied to CPU-bound traffic rather than normal transit forwarding. Build it carefully, verify it with counters and platform diagnostics, and never trust a copied sample policy until you have validated it on the actual platform and traffic profile.