5.3CoPP (Control Plane Policing)

Forwarding on a router or switch happens in hardware (the data plane), but packets the device itself must process—OSPF hellos, BGP updates, ARP, ICMP, SNMP, SSH—are punted to the CPU for software handling. If an attacker floods that path, the CPU saturates: adjacencies time out, routes drop, and even management access is lost—the network collapses even though forwarding hardware is untouched. An interface ACL can drop transit traffic, but it cannot govern the volume of packets that legitimately target the device. CoPP is the mechanism built for that job.

5.3.1Why the control plane needs protection

• The control plane is the CPU-based processing that computes routes, maintains adjacencies, and manages the device. Packets that reach it leave ASIC fast-path forwarding and are handled one at a time in software, so its throughput is orders of magnitude lower than the data plane's. That is why even a modest attack volume can incapacitate a device.
• CoPP applies a service policy to the virtual interface named control-plane, policing traffic bound for the CPU class by class. The key is that it is rate limiting rather than blocking: legitimate protocols still pass while only abnormal volume is dropped, aiming to keep adjacencies and management alive precisely when the device is busiest (that is, under attack).
• Two mechanisms are easily confused with CoPP: CPPr (Control Plane Protection), which further subdivides the control plane into host, transit, and CEF-exception subinterfaces, and access-class, which controls reachability of the management plane. Keep the mapping between planes (data, management, control) and tools straight.

5.3.2Building CoPP with MQC

• Step 1: classify. Define traffic types with ACLs and group them with statements such as class-map match-all CM-ROUTING. In practice you separate routing (OSPF/BGP/EIGRP/HSRP), management (SSH, SNMP, NTP, syslog), reachability checks (ICMP), and undefined (the remainder) into purpose-based classes. Coarse classification puts attack-prone ICMP and adjacency-keeping hellos in the same bucket, dropping them together.
• Step 2: define the policy. Under policy-map PM-COPP, assign each class a police <bps> conform-action transmit exceed-action drop. Give the routing class generous headroom (or deliberately leave it unpoliced) and constrain ICMP and undefined classes to low rates. Because class class-default catches everything unclassified, making it too strict kills protocols you did not anticipate.
• Step 3: apply and verify. In control-plane mode, apply service-policy input PM-COPP (the direction is input, meaning toward the CPU). Verify with show policy-map control-plane, checking per-class conform/exceed byte counts and drops to see whether legitimate traffic is exceeding. A safe rollout is to start with exceed-action transmit to measure only, set rates from the measurements, and then switch to drop.

Suppose you deploy CoPP to rescue a core router whose CPU hit 95% under an ICMP flood. In a hurry, you attach an ACL of permit ip any any to class-map match-all CM-ALL, define a single class in policy-map PM-COPP with police 32000 conform-action transmit exceed-action drop, and apply service-policy input PM-COPP under control-plane. CPU utilization does drop—but within tens of seconds all OSPF adjacencies fail, BGP sessions drop, and SSH becomes unstable. Concluding "CoPP is dangerous, remove it" is wrong; the fault is in the classification design. Squeezing all CPU-bound traffic into 32 kbps in one class means OSPF hellos and BGP keepalives are judged as exceeding in the same bucket as the attacking ICMP, so packets essential to adjacency maintenance are dropped at random—and once the dead interval elapses, adjacencies tear down and routes disappear. The correct design is separating classes by purpose: leave CM-ROUTING (OSPF/BGP/EIGRP/HSRP) unpoliced or at a generously high rate, give CM-MGMT (SSH/SNMP/NTP/syslog) a moderate rate, constrain CM-ICMP to a low rate, and keep class-default for the remainder at a value that is not excessively tight. The diagnostic tool is equally fixed: show policy-map control-plane shows which class is exceeding, revealing at a glance whether the drops hit attack traffic or legitimate protocols. Rising exceed counts on CM-ROUTING are direct evidence that its rate is too low relative to measured demand. Procedurally, rather than applying exceed-action drop immediately, you should have measured first with transmit, learned each class's steady-state rate, and only then switched to drop with roughly two to three times headroom. CoPP is a mechanism that protects you and also one that can take you down by your own hand; class design and the evidence behind each rate are the real substance of the configuration.

5.3.3Section summary

• CoPP polices traffic punted to the CPU on the control plane, protecting adjacencies and management from DoS and excessive control traffic (an interface ACL is no substitute)
• Build it with MQC: classify with ACLs, group with class-map, police within a policy-map, and apply service-policy input under control-plane. Split classes by purpose (routing, management, ICMP, class-default) and design rates per class
• Constraining everything in one class causes adjacency loss. Roll out by measuring with exceed-action transmit, set rates from that data, and verify collateral damage via conform/exceed counters in show policy-map control-plane