You have decided the control plane needs protecting - good. The next question is which tool: Control Plane Policing (CoPP) or Control Plane Protection (CPPr)? They are related, they are often confused, and the honest answer for most networks is "CoPP, and it is enough." This decision guide lays out exactly what each one does, backs the "CoPP is enough" case with a real police capture from our lab, and tells you the specific conditions under which reaching for CPPr actually pays off. It is part of the infrastructure security cluster.
The one-sentence version
CoPP is a single aggregate QoS policy on the entire control plane. CPPr splits the control plane into three subinterfaces and adds port-filtering and per-protocol queue-thresholding. CoPP is simpler and universal; CPPr is finer-grained and platform-dependent. If you remember nothing else, remember that CPPr is not a replacement for CoPP - it is a superset you layer on where the platform supports it.
Side by side
The case for CoPP: it works, and here is the proof
The strongest argument for "CoPP is enough for most" is that it demonstrably stops the attack it is meant to stop. In our CML lab we put a single, deliberately tight aggregate policy on EDGE1 - police ICMP to the control plane at 8 kbps, drop the excess:
access-list 150 permit icmp any any
class-map match-all PLZ-ICMP-CLASS
match access-group 150
policy-map PLZ-COPP
class PLZ-ICMP-CLASS
police 8000 conform-action transmit exceed-action drop
control-plane
service-policy input PLZ-COPPThen the Debian attacker flooded the router:
j@llmbits$ sudo ping -f -c 800 -i 0.002 192.168.99.1
--- 192.168.99.1 ping statistics ---
800 packets transmitted, 91 received, 88.625% packet loss, time 7446msEDGE1#show policy-map control-plane
Control Plane
Service-policy input: PLZ-COPP
Class-map: PLZ-ICMP-CLASS (match-all)
police:
cir 8000 bps, bc 1500 bytes
conformed 91 packets, 8918 bytes; actions:
transmit
exceeded 709 packets, 69482 bytes; actions:
drop91 conformed plus 709 dropped equals the 800 sent, and 91 is exactly what the flood got back. One aggregate policy, one command applied to control-plane, and the CPU never saw 709 of the 800 attack packets. That is the whole job. For the full build and tuning guidance, read our dedicated Control Plane Policing (CoPP) walkthrough.
The configuration difference, concretely
Both features use the same MQC building blocks - class-maps and policy-maps - so at first glance the configs look almost identical. The difference is entirely in where the policy attaches. CoPP binds one service-policy to the aggregate control-plane:
control-plane
service-policy input PLZ-COPPCPPr binds policies to named subinterfaces, and adds a policy type that has no CoPP equivalent - the port-filter that matches closed ports:
control-plane host
service-policy type port-filter input PLZ-PF-POLICY
service-policy input PLZ-CPPR-HOST
control-plane cef-exception
service-policy input PLZ-CEF-POLICYThat is the whole structural story. If your muscle memory already knows CoPP, CPPr is not a new language - it is the same MQC syntax pointed at three targets instead of one, plus type port-filter. The operational cost of CPPr is not learning new commands; it is having three or four policies to reason about and keep from dropping your own traffic, instead of one.
When CPPr earns its extra complexity
CoPP's limitation is that everything punted to the CPU shares one policer's fate. That is usually fine. It stops being fine in three specific situations, and those are exactly when CPPr is worth the effort:
A flood of un-switchable (cef-exception) traffic should not be allowed to starve your SSH management path. CPPr gives each subinterface its own budget.
On an exposed edge, port scans to closed ports waste CPU. Only CPPr's port-filter drops closed-port traffic before it is queued.
Queue-thresholding caps each protocol's slice of the punt queue, so one chatty protocol cannot block the rest even below the aggregate rate.
If none of those describe your environment - and for a great many enterprise and campus devices, none do - then CoPP alone is the right answer, and adding CPPr is complexity without a matching risk reduction.
Honest note: our platform only exposed CoPP
We proved CoPP with real counters above. We could not capture live CPPr output, because the Cisco IOL-XE (17.18) image our CML lab runs on does not implement the control-plane subinterfaces - control-plane host and show control-plane host open-ports both return % Invalid input. CPPr is a hardware and platform feature (common on ISR and ASR), so verify it on your own gear. We describe the CPPr model from Cisco's documentation and refuse to fabricate show output for it. The full CPPr model, including the port-filter config, is in our companion article on Control Plane Protection (CPPr).
The decision, in one flow
Start with CoPP on every device - it is universal, low-risk, and proven. Then ask: is this box directly exposed to untrusted networks, scanned frequently, or does it need hard isolation between control-plane traffic classes? If yes, and the platform supports it, layer CPPr on top for the port-filter and per-subinterface policing. If no, stop at CoPP. You are not choosing between them so much as deciding how far up the ladder your particular device needs to climb.
A common misconception
Engineers sometimes treat CPPr as "the new CoPP" and assume enabling it replaces the aggregate policy. It does not. If you configure CPPr subinterface policies but never build a sensible baseline of protection, you can end up with less coverage than a good single CoPP policy would give you, because traffic that does not match any of your subinterface classes may pass unpoliced. The correct mental model is additive: a solid CoPP-style baseline of classification and policing first, then the CPPr-specific wins (isolation, port-filter, queue-threshold) layered on. Do not tear out working CoPP to "upgrade" to CPPr - extend it.
The other frequent mistake is policing management traffic into the ground. In both models, the failure you must avoid is dropping SSH from your own NOC or starving a routing protocol. Whichever tool you deploy, explicitly permit and generously rate the traffic that keeps the box reachable and converged, and baseline the real punt rate before you set any conform value.
Frequently asked
Does CPPr improve on CoPP for a typical enterprise core?
Usually not enough to justify the complexity. A well-tuned CoPP policy on a core device that is not directly exposed to untrusted hosts already stops the volumetric attacks that matter. CPPr's port-filter shines on an exposed edge that gets scanned; on a protected core it solves a problem you may not have.
If my platform does not support CPPr, am I exposed?
No. CoPP alone is a legitimate, complete control-plane defense - it is what our lab used to absorb the flood. CPPr adds isolation and closed-port filtering, but the absence of CPPr is not a gap you have to panic about as long as CoPP is in place and tuned.
Can I run both at once?
On platforms that support CPPr, yes, and that is the intended design. Keep a baseline of classification and policing, and use the CPPr subinterfaces for the extra granularity. They are complementary layers, not an either/or.
Key Takeaways
- CoPP is one aggregate policy; CPPr subdivides the control plane into host, transit, and cef-exception subinterfaces plus port-filtering and queue-thresholding.
- CoPP is enough for most networks and it is proven - our 8 kbps policer dropped 709 of 800 flood packets (88.6% loss) with a single command on
control-plane. - Reach for CPPr only when you need class isolation, you face constant port scanning (the port-filter), or one protocol can flood the punt queue (queue-thresholding).
- They stack, they do not compete. Deploy CoPP everywhere; add CPPr where the platform and the threat model justify it.
- Platform reality: our IOL lab exposed CoPP but not CPPr's subinterfaces, so we proved CoPP live and describe CPPr from documentation.
This is one decision inside a larger hardening story. Work through the rest of the infrastructure security cluster to pair control-plane defense with anti-spoofing, management-plane lockdown, and authenticated NTP.
