Control Plane Policing (CoPP): Protecting the CPU

The control plane of a switch is designed for thousands of packets per second, not millions. When a loop, a misconfigured host or an attack sends traffic that has to be punted to the CPU — ARP floods, ICMP, TTL-expired packets, routing updates — the CPU saturates, routing protocols drop their adjacencies, and the device stops forwarding. Control Plane Policing is the mechanism that keeps that from happening: it applies rate limits to traffic destined to the CPU, with real traffic still passing at line rate through the data plane. This article covers the model, the default policies you should understand before replacing them, and how to tune without locking yourself out.

The model: class maps, policy maps, control plane

CoPP reuses the modular QoS CLI. You classify traffic into classes, apply policing actions per class, attach the policy to the control plane, and the device handles the rest.

! 1. classify
class-map type control-plane match-any COPP-ARP
 match protocol arp
class-map type control-plane match-any COPP-ROUTING
 match access-group name ACL-ROUTING-PROTOS
class-map type control-plane match-all COPP-ICMP
 match access-group name ACL-ICMP-TO-CPU

! 2. police
policy-map type control-plane COPP-POLICY
 class COPP-ROUTING
  police cir 256000 kbps bc 310 ms conform transmit violate drop
 class COPP-ARP
  police cir 4000 kbps bc 32 ms conform transmit violate drop
 class COPP-ICMP
  police cir 256 kbps bc 310 ms conform transmit violate drop
 class class-default
  police cir 100 kbps bc 310 ms conform transmit violate drop

! 3. attach
control-plane
 service-policy input COPP-POLICY

Two syntax details vary by platform and are worth checking before copying: on some families the policy map is declared with policy-map type control-plane and classes with class-map type control-plane, while other platforms use the plain MQC form and a control-plane configuration mode. The policing units also differ, some accepting pps and others kbps or bps.

Understand the defaults before you replace them

Most modern platforms ship with a default CoPP policy already applied — on Catalyst switches this is the auto-CoPP policy with a long list of classes covering ICMP redirects and unreachable, glean traffic, receive traffic, options, broadcast, multicast punt paths, MTU failures, DHCP snooping, IPv6 ND, and more. On Nexus platforms there are named default policies — strict, moderate and lenient — with published rate values per class.

Replacing a working default with your own first attempt is a common way to create an outage. Start by reading the applied policy (show policy-map type control-plane, show policy-map interface control-plane) and note which classes are actually seeing traffic, then tune only the classes that are being exceeded.

Tuning without breaking routing

The failure mode to avoid is starving a legitimate protocol. Police values that are too low cause BGP or OSPF hellos to be dropped, which looks exactly like a link problem: adjacency flaps, routes disappear, and the logs point at the protocol rather than at CoPP. Three habits prevent it:

• Leave headroom. Set limits comfortably above the steady-state rate of each class — several times, not several percent.
• Classify routing protocol traffic separately and give it generous limits. A shared "everything else" class that also carries hellos is a trap.
• Never police management access to the point of exclusion. If SSH and SNMP share a class with heavy punt traffic, a storm can lock you out of the device exactly when you need to fix it. Verify console access before applying a new policy.

show policy-map type control-plane
show policy-map interface control-plane
show control-plane host open-ports
show platform hardware qos control-plane

The interface control-plane output shows conform and violate counters per class. A class that is permanently in violation is either under-provisioned or is genuinely absorbing an attack; distinguishing the two requires knowing normal baselines, which is another reason to export the counters to a monitoring platform before an incident makes them interesting.

CoPP in context

CoPP protects the last hop to the CPU; it does not replace network-level defences. Volumetric attacks should be dropped upstream or in the data plane where possible — either by dropping traffic at the edge with flow-based filtering as described in BGP FlowSpec DDoS filtering, or by discarding traffic toward a blackhole next hop as in RTBH remotely triggered blackhole. Use flow telemetry to work out what is actually arriving before you tune — Flexible NetFlow configuration covers the collection side. The right architecture is layered: data-plane filtering for volume, CoPP for the residual that must reach the CPU.

原文链接：https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_nx-os-cfg/sec_cppolicing.pdf