Control Plane Policing (CoPP) auf Cisco-Routern: Wann ist es Pflicht?

Control Plane Policing (CoPP) schützt die CPU und die Control Plane von Cisco-Routern vor Überlast durch Control-Plane-Traffic (z. B. Scans, DoS, fehlerhafte Broadcasts oder Routing-Stürme). Im Produktivbetrieb ist CoPP nicht „nice to have“, sondern in vielen Enterprise-Szenarien Pflicht, weil ein CPU-Overload sofort zu massiven Auswirkungen führt: Routing-Nachbarn flappen, VPN bricht, Management wird unzugänglich und der Router wird zum Single Point of Failure. Dieses Tutorial zeigt, wann CoPP als Mindeststandard gelten sollte, welche Traffic-Kategorien typischerweise geschützt werden und wie Sie CoPP so implementieren, dass Betrieb und Fehlersuche nicht leiden.

Was CoPP schützt: Control Plane vs. Data Plane

CoPP betrifft Pakete, die auf dem Router selbst terminiert werden (Control Plane): Routing-Protokolle, Management, ICMP an den Router, ARP/NDP (je Plattform) und weitere Steuerpakete. Datenverkehr, der nur durch den Router geroutet wird (Data Plane), ist nicht das Ziel von CoPP.

• Control Plane: Pakete an Router-IPs (Management, Routing, Tunnel-Endpunkte)
• Data Plane: Transit-Traffic (Routing/Forwarding), typischerweise separat behandelt
• Risiko: Control-Plane-Last kann CPU binden und Routing/VPN destabilisieren

Wann CoPP Pflicht ist (Enterprise-Mindestkriterien)

CoPP wird zur Pflicht, wenn die Wahrscheinlichkeit von Control-Plane-Last hoch ist oder die Auswirkungen eines CPU-Overloads kritisch sind. Typische Pflicht-Szenarien sind Edge-Router, WAN-exponierte Geräte und Multi-Branch-Hubs.

• Internet Edge / DIA: Router ist direkt am Internet oder Provider-Netz exponiert
• Dual-ISP/BGP Edge: BGP Sessions, Policy-Updates, größere Control-Plane-Last
• VPN Hub (DMVPN/Hub-and-Spoke): viele Tunnel-Endpunkte, DPD/Rekey Traffic
• Multi-tenant Segmente: Guest/IoT nahe am Router, höheres Scan-/Noise-Risiko
• Compliance-Anforderung: „Management Plane Protection“ als Sicherheitskontrolle

Wann CoPP meist optional ist

In sehr kleinen, abgeschotteten Netzen kann CoPP optional sein – aber nur, wenn Management strikt isoliert ist und keine WAN-Exposition besteht. In Enterprise-Umgebungen ist „optional“ eher die Ausnahme.

• Isolierte Lab-Umgebung ohne WAN-Exposition
• Router nur intern, MGMT nur aus dediziertem MGMT-Netz, starke ACLs
• Sehr geringe Komplexität (keine VPN-Hubs, kein BGP, wenige Neighbors)

CoPP-Designprinzip: Erlauben, priorisieren, begrenzen

CoPP ist kein „block everything“. Es ist ein Schutz, der notwendige Control-Plane-Protokolle zulässt, aber rate-limited. Wichtig ist, dass Sie kritische Protokolle priorisieren und Nicht-Notwendiges drosseln oder verwerfen.

• Kritisch: Routing-Protokolle (OSPF/BGP), VPN-Control (IKE), Management (SSH/AAA)
• Wichtig: ICMP begrenzt (für Diagnostik), aber nicht unlimitiert
• Noise: Scans, unerwartete Protokolle, Flooding → stark begrenzen/deny
• Regel: initial konservativ, dann mit Telemetrie/Logs tunen

Traffic-Kategorien für CoPP (Praxis-Katalog)

Teilen Sie Control-Plane-Traffic in wenige Klassen. Das reduziert Komplexität und macht Tuning möglich. Die exakten Details sind plattformspezifisch, das Modell bleibt stabil.

• MGMT: SSH, TACACS/RADIUS, SNMPv3 (falls genutzt)
• ROUTING: OSPF, BGP, ggf. EIGRP (wenn verwendet)
• VPN: IKEv2/IPsec Control (falls Router VPN terminiert)
• ICMP: Ping/Traceroute an Router (diagnostisch), rate-limited
• DEFAULT/NOISE: alles andere, stark begrenzen oder deny

Implementierungsmuster: Class-Maps + Policy-Map auf Control Plane

Das Standardmuster ist eine MQC-Policy auf der Control Plane. Sie matchen Traffic per ACLs in Klassen und polizen pro Klasse. Werte (pps/bps) hängen von Plattform und Umgebung ab und sollten im Testfenster validiert werden.

CLI: CoPP-Gerüst (konzeptionell)

ip access-list extended ACL-COPP-MGMT
 permit tcp 10.10.10.0 0.0.0.255 any eq 22
 permit udp 10.10.10.50 0.0.0.0 any eq 161
ip access-list extended ACL-COPP-ROUTING

permit ospf any any

permit tcp any any eq 179
ip access-list extended ACL-COPP-ICMP

permit icmp any any echo

permit icmp any any echo-reply

permit icmp any any time-exceeded

permit icmp any any unreachable
class-map match-any CM-COPP-MGMT

match access-group name ACL-COPP-MGMT
class-map match-any CM-COPP-ROUTING

match access-group name ACL-COPP-ROUTING
class-map match-any CM-COPP-ICMP

match access-group name ACL-COPP-ICMP
policy-map PM-COPP

class CM-COPP-ROUTING

police 64000 conform-action transmit exceed-action transmit violate-action drop

class CM-COPP-MGMT

police 64000 conform-action transmit exceed-action transmit violate-action drop

class CM-COPP-ICMP

police 32000 conform-action transmit exceed-action drop violate-action drop

class class-default

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

service-policy input PM-COPP

Wichtige Designhinweise: Was Sie nicht „kaputtpolicen“ dürfen

CoPP kann Routing und Betrieb stören, wenn Sie zu aggressiv sind. Schützen Sie deshalb kritische Protokolle mit ausreichend Headroom und testen Sie Konvergenz, VPN-Rekey und Managementzugriff unter Last.

• Routing: OSPF/BGP dürfen bei Peak nicht gedroppt werden (Session-Flaps vermeiden)
• VPN: IKE/DPD/Rekey dürfen nicht kollabieren (Tunnel-Flaps vermeiden)
• Management: SSH/AAA muss auch im Incident nutzbar bleiben
• Diagnostik: ICMP begrenzen, aber nicht vollständig blockieren

Verifikation: Wie Sie CoPP korrekt prüfen

CoPP ist nur dann wirksam, wenn Zähler steigen und Drops nachvollziehbar sind. Prüfen Sie Policies, CPU und Logs. Zusätzlich sollten Sie einen Test für ICMP und Management durchführen.

CLI: CoPP-Checks (typisch)

show policy-map control-plane
show processes cpu sorted
show logging | last 50

UAT/Acceptance: Testszenarien für CoPP

Setzen Sie CoPP nicht „blind“ in Produktion. Testen Sie in einem Wartungsfenster: Managementzugriff, Routing-Stabilität, VPN-Stabilität und Diagnosefähigkeit. Dokumentieren Sie Evidence (Policy-Zähler).

• Test 1: SSH Login und Kommandoausführung stabil
• Test 2: OSPF/BGP Neighbors bleiben stabil unter Last/Noise
• Test 3: VPN Rekey/DPD ohne Flaps (falls relevant)
• Test 4: Ping/Traceroute funktioniert, aber Flooding wird gedroppt

Evidence-Set (Copy/Paste)

show policy-map control-plane
show processes cpu sorted
show ip ospf neighbor
show bgp summary
show crypto ikev2 sa
show logging | last 100

Betriebsmodell: Monitoring und Tuning von CoPP

CoPP ist keine „einmal konfigurieren“ Funktion. Sie muss überwacht und bei Änderungen (neue Protokolle, neue Hubs, mehr Branches) nachjustiert werden. Das NOC sollte CoPP-Drops als Signal sehen.

• Alarme: steigende Drops in CoPP-Klassen, CPU-Spikes
• Runbook: bei Drops → Quelle identifizieren, Segment isolieren, Policies anpassen
• Change Control: CoPP-Änderungen peer-reviewed, Pre-/Post-Checks
• Dokumentation: Klassen, Ziele, erlaubte Quellen (MGMT), Schwellen

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.