Control-Plane Protection richtig dimensionieren: CoPP Policies in der Praxis

Control-Plane Protection (CoPP/CPPr) schützt IOS XE Router davor, dass die CPU durch Scans, Floods oder Fehlkonfigurationen überlastet wird. Die Herausforderung ist nicht „CoPP an“, sondern „CoPP richtig dimensioniert“: Zu locker bringt wenig Schutz, zu streng bricht Routing, Management oder Troubleshooting (z. B. ICMP) – oft erst im Incident. Ein praxistauglicher Ansatz kombiniert Baseline-Policies (immer erlaubt), gezielte Rate-Limits pro Protokoll und eine messbasierte Anpassung anhand von Countern und echten Traffic-Profilen.

Was CoPP wirklich schützt

CoPP wirkt auf Traffic, der in die Control Plane (CPU) gelangt: Pakete an Router-IPs, Routing-Protokolle, Management (SSH/SNMP) und bestimmte Exceptions/Punt-Paths. Transit-Traffic in der Data Plane wird nicht durch CoPP „schneller“ – CoPP verhindert, dass Control-Plane-Last das System destabilisiert.

• Schützt CPU vor: Scans, ICMP-Floods, SSH-Bruteforce, Routing-Storms
• Schützt nicht direkt: Data-Plane Congestion (dafür QoS/QFP/Queues)
• Wichtig: CoPP ist ein Guardrail, kein Ersatz für Firewall/ACL

Dimensionierungsprinzip: Baseline messen, dann policen

„Richtig dimensionieren“ heißt: du kennst dein normales Control-Plane-Profil und setzt Policer so, dass Normalbetrieb immer durchgeht, aber Anomalien gedrosselt werden. Arbeite mit einem Messfenster und Counters, nicht mit Bauchgefühl.

• Ist-Profil: welche Protokolle, welche pps im Normalbetrieb?
• Reserve: Policer über Normalwert (Sicherheitsmarge)
• Schutz: klare Drop/Remark-Strategie bei Überschuss

Messlogik

$\text{Policer}\approx \text{Normal}\times \text{Sicherheitsfaktor}$

CoPP-Bausteine in IOS XE: Class-Map, Policy-Map, Control-Plane

CoPP wird über MQC umgesetzt: Du definierst Klassen (match), Policies (police/queue) und bindest sie an control-plane. Wichtig ist eine klare Klassenhierarchie: erst kritische Protokolle, dann „default“ begrenzen.

Minimalstruktur

class-map match-any CM_CP_SSH
 match protocol ssh
policy-map PM_COPP

class CM_CP_SSH

police 64000 conform-action transmit exceed-action drop

class class-default

police 16000 conform-action transmit exceed-action drop
control-plane

service-policy input PM_COPP

Welche Protokolle du in der Praxis separat klassifizierst

Eine gute Policy trennt mindestens Management, Routing und „allgemeines ICMP/sonstiges“. Je nach Umgebung kommen BGP/OSPF, NTP, SNMP, DHCP Relay oder IPsec/IKE hinzu.

• Management: SSH, SNMP
• Routing: OSPF/EIGRP/BGP (je nach Einsatz)
• ICMP: Ping/Traceroute (nicht komplett blocken)
• Infrastructure: NTP, Syslog (wenn an Router-IP terminiert)
• VPN/Edge: IKE/IPsec (wenn Router VPN terminiert)

Praxis-Policy: Baseline-CoPP für Branch/WAN Edge

Dieses Beispiel ist bewusst pragmatisch: Es erlaubt die wichtigsten Control-Plane-Protokolle mit moderaten Policern und schützt die Default-Klasse. Werte sind Startpunkte und müssen mit Countern verifiziert werden.

Class-Maps (Beispiel)

class-map match-any CM_CP_SSH
 match protocol ssh
class-map match-any CM_CP_SNMP

match protocol snmp
class-map match-any CM_CP_ICMP

match protocol icmp
class-map match-any CM_CP_OSPF

match protocol ospf

Policy-Map (Beispiel, Startwerte)

policy-map PM_COPP
 class CM_CP_OSPF
  police 256000 conform-action transmit exceed-action drop
 class CM_CP_SSH
  police 128000 conform-action transmit exceed-action drop
 class CM_CP_SNMP
  police 128000 conform-action transmit exceed-action drop
 class CM_CP_ICMP
  police 64000 conform-action transmit exceed-action drop
 class class-default
  police 64000 conform-action transmit exceed-action drop

Bindung an Control Plane

control-plane
 service-policy input PM_COPP

Dimensionierung: Wie du Startwerte sinnvoll ableitest

Im Betrieb ist „pps“ oft entscheidender als „bps“, weil Control-Plane-Last stark paketgetrieben ist. Viele kleine Pakete (ICMP, Scans) belasten die CPU stärker als wenige große. Dimensioniere daher mit Blick auf typische pps-Spitzen.

• Routing-Protokolle: genug Reserve für Reconvergence/Neighbor-Events
• SSH: niedrig halten, aber nicht so niedrig, dass Logins instabil werden
• SNMP: Polling-Intervalle berücksichtigen (viele Interfaces → viele OIDs)
• ICMP: begrenzen, aber nicht komplett blocken (PMTUD/Diag)

Faustformel für pps→bps (nur zur Orientierung)

$\text{bps}\approx \text{pps}\times \text{avgPacketSize}\times 8$

Verifikation: CoPP richtig auswerten (Counters sind alles)

Nach Aktivierung musst du prüfen, ob legitimer Traffic gedroppt wird. show policy-map control-plane zeigt pro Klasse die Match- und Drop-Zähler. Arbeite wieder mit Messfenstern (t1/t2).

CoPP Counters prüfen

show policy-map control-plane

Ergänzende Checks

show processes cpu sorted
show logging | include COPP|CPU|PUNT
show ip ospf neighbor
show ip bgp summary

Typische Fehler bei CoPP-Policies (und wie du sie vermeidest)

Die häufigsten CoPP-Probleme entstehen durch zu grobe Klassen, falsche Reihenfolge oder zu aggressive Default-Policer. Ein Klassiker: ICMP wird zu hart gedrosselt und PMTUD bricht – danach wirken VPN/HTTPS „kaputt“.

• ICMP komplett blockiert → PMTUD/Diag kaputt
• Routing-Protokolle nicht separat klassifiziert → Reconvergence dropt
• SNMP zu hart → Monitoring „flappt“, false alarms
• Default-Policer zu niedrig → legitime punts droppen

Härtung ergänzen: CoPP ist kein Ersatz für ACLs

CoPP schützt die CPU, aber du solltest Management zusätzlich am Rand begrenzen (VTY ACL, SNMP ACL). So reduzierst du den „Angriffsinput“, bevor er überhaupt die Control Plane erreicht.

VTY-ACL (Beispiel)

ip access-list standard VTY_MGMT
 permit 10.255.0.0 0.0.255.255
 deny any
line vty 0 15
 transport input ssh
 access-class VTY_MGMT in

Rollout-Pattern: sicher aktivieren ohne Lockout

Aktiviere CoPP schrittweise: erst Monitoring (Counters), dann moderate Policers, dann nachjustieren. In kritischen Umgebungen ist ein Pilot-Rollout (ein Standort) Pflicht.

• Pilot: ein Router, eine Woche Beobachtung
• Wellen: nach Standort-/Rollenclustern ausrollen
• Bei Drops: Policer erhöhen oder Klassen verfeinern

Quick-Runbook: CoPP dimensionieren in der Praxis

Diese Sequenz ist für Betrieb gedacht: Baseline, Aktivierung, Messfenster, Anpassung.

! Baseline
show policy-map control-plane
show processes cpu sorted
show ip ospf neighbor
show ip bgp summary
! Aktivieren/ändern

configure terminal

! CoPP config

end
! Messfenster (t1/t2)

show policy-map control-plane

show processes cpu sorted

show logging | include COPP|CPU

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.