Control Plane Policing (CoPP): Router und Switches gegen Angriffe schützen

Control Plane Policing (CoPP) ist einer der wirkungsvollsten Schutzmechanismen auf Cisco Routern und Switches, um die Control Plane gegen Angriffe, Fehlkonfigurationen und „harmlosen“ Hintergrundlärm abzusichern. Während Datenverkehr (Data Plane) in modernen Plattformen weitgehend in Hardware/ASICs verarbeitet wird, bleibt die Control Plane (CPU, Routing-Prozesse, Management-Daemons) ein knappes Gut: Wenn sie überlastet wird, brechen Routing-Nachbarschaften weg, BGP-Sessions flappen, ARP/ND/IGMP/MLD werden instabil, und selbst SSH oder API-Zugriffe sind nicht mehr möglich. Genau das ist das Ziel vieler Angriffe: nicht unbedingt Bandbreite zu sättigen, sondern das Gerät durch gezielte Pakete zu destabilisieren. CoPP setzt hier an, indem es Control-Plane-Traffic klassifiziert (z. B. Routing-Protokolle, ICMP/ICMPv6, ARP/ND, Management, SNMP, NTP, DHCP, Multicast-Control) und pro Klasse policet – also Rate Limits und Prioritäten erzwingt. Der entscheidende Profi-Punkt ist jedoch: CoPP ist kein „einmal einschalten“-Feature. Ein zu hartes CoPP erzeugt schnell Selbstschäden („Self-DoS“), weil legitimer Control-Plane-Traffic gedroppt wird. Ein zu lockeres CoPP ist wirkungslos, weil es Angriffe nicht dämpft. Ziel ist daher ein sauberes, auditierbares CoPP-Design: minimal notwendige Control-Plane-Funktionen erlauben, Missbrauch begrenzen, Plattformbesonderheiten berücksichtigen und die Konfiguration so gestalten, dass sie über Releases, neue Services (z. B. IPv6, EVPN, Telemetry) und Wachstum stabil bleibt. Dieser Artikel zeigt professionelle Best Practices, typische Fehlerbilder und ein praxistaugliches Vorgehensmodell, um CoPP in Enterprise- und providerähnlichen Cisco-Netzen sicher auszurollen.

Control Plane vs. Data Plane: Warum CoPP überhaupt notwendig ist

Viele Netzwerkstörungen wirken zunächst wie „Routing ist kaputt“ oder „das Device ist langsam“, haben aber eine gemeinsame Ursache: Control-Plane-Überlast. Die Data Plane kann Millionen Pakete pro Sekunde in Hardware forwarden, während die Control Plane nur einen Bruchteil davon verkraftet. Sobald zu viele Pakete an die CPU gelangen, steigt die Latenz für Routing-Events, Keepalives, ARP/ND, Protokoll-Updates und Management-Anfragen. Besonders gefährlich sind dabei nicht nur klassische DDoS-Angriffe, sondern auch interne Fehlkonfigurationen wie Broadcast-/Multicast-Stürme, flappende Interfaces, falsch getunte Protokolltimer oder fehlerhafte Endgeräte, die RA/ND/IGMP spammen.

• Routing-Instabilität: OSPF/IS-IS/BGP Sessions können durch CPU-Delay flappen.
• Management-Verlust: SSH/HTTPS/API werden träge oder nicht erreichbar – genau im Incident.
• Nachbarschaftsprobleme: ARP (IPv4) oder Neighbor Discovery (IPv6) werden unzuverlässig.
• Control-Plane-Queueing: Selbst legitime Protokolle werden „zu viel“, wenn keine Dämpfung existiert.

Was CoPP technisch macht: Klassifizieren, policen, priorisieren

CoPP setzt an der Control Plane an: Pakete, die zur CPU (oder zu Control-Plane-Prozessen) gehen, werden anhand definierter Kriterien klassifiziert (ACLs, Protokollfelder, Ports, ICMP-Typen, Routing-Protokolle). Anschließend werden sie pro Klasse mit Policies belegt – typischerweise Policer (Rate Limits), teilweise auch Prioritäten und Drops. Der Kern ist ein MQC-ähnliches Modell (Class-Map/Policy-Map), das sich von Plattform zu Plattform unterscheidet, aber konzeptionell gleich bleibt: Sie definieren Klassen, ordnen sie in einer Policy an und wenden die Policy an die Control Plane an.

• Classify: Welche Pakete gehören zu Management, Routing, ICMP, ARP/ND, Multicast-Control?
• Police: Welche Rate ist legitim? Was wird gedroppt, wenn es darüber liegt?
• Protect: Control-Plane bleibt responsiv, auch wenn einzelne Klassen „aus dem Ruder laufen“.

Die wichtigste Best Practice: CoPP ist ein Schutzgitter, kein Firewall-Ersatz

CoPP schützt die Control Plane. Es ersetzt keine Datenpfad-Segmentierung, keine Interface-ACLs und keine Firewall. Ein häufiges Anti-Pattern ist, CoPP als „globale Security-Policy“ zu missbrauchen. Das führt zu unklarer Verantwortung: Manche Pakete werden im Data Plane gefiltert, andere in der Control Plane – und im Incident weiß niemand mehr, warum etwas gedroppt wird. Profi-Regel: Data Plane Regeln gehören in Data Plane Filter (ACLs, ZBFW, Firewalls). CoPP beschränkt sich auf Control-Plane-relevanten Traffic und schützt das Gerät als System.

CoPP-Designprinzipien: Klassenmodell statt Einzellisten

Ein wartbares CoPP-Design folgt einem Klassenmodell. Statt Dutzende Mikro-ACLs zu bauen, definieren Sie wenige, stabile Klassen, die Ihre betrieblichen Anforderungen abbilden. Typische Klassen, die sich in Enterprise-Setups bewährt haben:

• Routing: OSPF, IS-IS, BGP, EIGRP (wo relevant), ggf. BFD.
• Neighbor/Discovery: ARP (IPv4) und ND/RA/RS (IPv6), ggf. DHCPv6.
• Management: SSH, HTTPS/API, NETCONF/RESTCONF, gNMI/gRPC (je Umfeld), TACACS/RADIUS.
• Monitoring: SNMP, Syslog, Telemetry, NetFlow/IPFIX Export (je nach Design zur CPU).
• ICMP/ICMPv6: Diagnostik und PMTUD-relevante Typen (besonders wichtig in IPv6).
• Multicast-Control: IGMP/MLD, PIM/Multicast-Routing, falls Control-Plane-abhängig.
• Default/Unknown: Alles andere, meist stark gedrosselt oder gedroppt.

Dieses Modell ist auditierbar: Jede Klasse hat einen Zweck, einen Owner (NetOps/SecOps), eine Rate-Entscheidung und ein Monitoring.

Routing-Klassen: Protokolle schützen, ohne Nachbarschaften zu destabilisieren

Routing-Protokolle sind kritisch, aber in normalen Netzen ist ihr Trafficvolumen relativ klein. Genau deshalb eignet sich CoPP hier hervorragend: Sie erlauben Routing-Control-Plane, begrenzen aber Spitzen, die z. B. bei Flapping, LSA-/LSP-Stürmen oder Session-Attacken auftreten können.

• OSPF/IS-IS: Flooding kann bei Instabilität stark steigen; CoPP darf es dämpfen, aber nicht so hart, dass Adjacencies flappen.
• BGP: TCP-basierte Sessions; CoPP sollte BGP-Ports/Peers schützen, aber nicht Keepalives/Updates „abwürgen“.
• BFD: Sehr empfindlich gegenüber Drops. Wenn BFD genutzt wird, muss CoPP BFD passend priorisieren, sonst erzeugen Sie Fast-Failover-Flapping.

Ein bewährtes Vorgehen ist, Routing-Protokolle in einer eigenen Klasse mit konservativer, aber nicht zu niedriger Rate zu führen, und ihre Drops explizit zu überwachen. Damit erkennen Sie früh, wenn das Netz „lärmig“ wird.

ARP, ND und RA: Die häufigste Self-DoS-Falle in IPv6-Umgebungen

In Dual-Stack- und IPv6-Netzen ist Neighbor Discovery (ND) und Router Advertisement (RA) funktional unverzichtbar. Wird ND/RA zu hart gepolicet, treten Symptome auf, die wie „IPv6 ist kaputt“ wirken: Hosts verlieren Default Router, DAD schlägt fehl, neue Nachbarn werden nicht gelernt, oder Verbindungen brechen sporadisch. Gleichzeitig sind ND/RA eine Angriffsfläche (Rogue RA, ND Flooding). Profi-Ansatz: ND/RA in eine eigene CoPP-Klasse, ausreichend Rate für Normalbetrieb, plus ergänzende First-Hop-Security-Features (RA Guard, DHCPv6 Guard), die Missbrauch schon am Access-Port blocken.

• IPv4: ARP-Spikes bei L2-Stürmen sind üblich; CoPP kann CPU schützen.
• IPv6: ND/RA/RS/NS/NA sind Control Plane; CoPP muss sie funktional zulassen.
• Security: Missbrauch lieber durch L2-Guard-Mechanismen begrenzen als durch „ND fast blocken“.

Für ND/RA ist RFC 4861 maßgeblich. Für Path MTU Discovery in IPv6, das ICMPv6 Packet Too Big benötigt, ist RFC 8201 relevant.

ICMP und ICMPv6: Dämpfen ja, blind blocken nein

ICMP ist ein klassischer Angriffsvektor (Ping Floods, Smurf-ähnliche Muster), aber auch ein Betriebswerkzeug. ICMPv6 ist zusätzlich Protokollbestandteil. Ein professionelles CoPP-Design behandelt ICMP/ICMPv6 differenziert: wichtige Typen (z. B. Packet Too Big, Time Exceeded, Destination Unreachable) müssen durchkommen, Diagnostik (Echo) wird kontrolliert, und Missbrauch wird gedrosselt.

• IPv6 PMTUD: Packet Too Big ist kritisch; zu harte Policer erzeugen „nur große Pakete brechen“.
• Diagnostik: Echo kann auf Monitoring-Quellen eingeschränkt werden (z. B. nur NMS-Subnets).
• Schutz: ICMP-Floods werden durch Policing begrenzt, ohne komplette Blindheit zu erzeugen.

Management-Traffic: Schutz der Zugänge, ohne den Incident zu verschlimmern

Management ist paradox: Genau im Angriff oder Incident brauchen Sie Zugriff. Gleichzeitig ist Management ein beliebtes Ziel (SSH-Bursts, HTTPS Scans, SNMP Abuse). CoPP sollte Management-Traffic so policen, dass Brute-Force und Scan-Spikes gedämpft werden, legitime Zugriffe aber stabil bleiben. Entscheidend ist hier Scope: Wenn Management sowieso über ein Management-VRF oder Out-of-Band-Netz läuft, kann CoPP sehr strikt sein, weil nur wenige Quellen zulässig sind.

• Source-Restriktion: Management nur aus definierten Netzen zulassen (am besten per ACL plus CoPP-Klasse).
• Rate-Limits: Ausreichend für normale Ops und Automatisierung, aber dämpfend gegen Bursts.
• Telemetry/API: Automations-Workloads können mehr Control-Plane-Traffic erzeugen als klassisches SSH; Raten realistisch planen.

Monitoring und Logs: CoPP ist nur so gut wie seine Sichtbarkeit

Ein häufiger Fehler ist, CoPP zu konfigurieren und danach nie wieder hinzusehen. Professioneller Betrieb bedeutet: Sie überwachen Drops pro Klasse, korrelieren sie mit Ereignissen (Link-Flaps, Routing-Flooding, Scan-Wellen) und passen Raten kontrolliert an. Dabei ist „zu viel Logging“ ebenfalls riskant, weil Logs selbst die CPU belasten können. Besser sind Counters und Telemetry, ergänzt durch gezielte Syslog-Events für echte Grenzfälle.

• Counters pro Klasse: Steigende Drops sind ein Frühwarnsignal für Angriffe oder Netzinstabilität.
• Baseline: Normalwerte für Control-Plane-Traffic ermitteln, bevor Sie Grenzen „hart“ setzen.
• Rate-limited Logging: Nur für wichtige Drop-Klassen, sonst Self-DoS durch Log-Flood.

Der Rollout-Blueprint: CoPP sicher einführen, ohne Selbstschäden

CoPP sollte wie ein Produkt ausgerollt werden: mit Baseline, Pilot, schrittweiser Härtung und klaren Rollback-Kriterien. Das reduziert das Risiko, dass Sie legitimen Traffic abschneiden.

• Phase 1: Observability: Zunächst nur messen, welche Control-Plane-Klassen welche Raten haben (Baseline).
• Phase 2: Soft Policing: Konservative Limits setzen, um extreme Peaks zu dämpfen, ohne normale Last zu beeinflussen.
• Phase 3: Härtung: Klassen differenzieren (z. B. ICMPv6 Typen, Management Sources), Limits enger setzen, Unknown hart begrenzen.
• Phase 4: Standardisierung: Templates pro Gerätekategorie (Access, Distribution, Core, Edge), versioniert und reviewt.
• Phase 5: Day-2 Betrieb: Monitoring, regelmäßige Reviews nach Architekturänderungen (IPv6-Rollout, EVPN, Telemetry).

Typische Fehlerbilder und ihre CoPP-Ursachen

• BGP/OSPF flappen „grundlos“: Routing-Klasse zu hart gepolicet oder CoPP dropt BFD; CPU-Latenz steigt.
• IPv6 sporadisch kaputt: ND/RA/ICMPv6 Packet Too Big zu hart; DAD/Default Router instabil.
• IPTV/Multicast instabil: IGMP/MLD/PIM Control Traffic gedrosselt; Querier/Join/Prune-Verhalten leidet.
• Kein SSH im Incident: Management-Klasse zu niedrig oder Sources nicht sauber begrenzt; Angriffsburst verdrängt Ops-Zugriffe.
• CPU hoch trotz CoPP: Falsche Klassifizierung (Traffic fällt in „default“ ohne wirksame Police) oder viele Pakete treffen CPU vor CoPP (plattformabhängig).

Best Practices: CoPP als Security-Standard im Netzwerk

• Klassen klein halten: Wenige, stabile Klassen (Routing, Neighbor, ICMPv6, Management, Monitoring, Default).
• IPv6 bewusst behandeln: ND/RA und PMTUD-relevantes ICMPv6 sicher erlauben, nicht „wegpolicen“.
• Guard-Features ergänzen: RA Guard, DHCPv6 Guard, uRPF und L2-Schutz reduzieren Missbrauch, bevor er die CPU erreicht.
• Baselines messen: Limits nie „nach Gefühl“ setzen; reale Control-Plane-Last kennen.
• Templates pro Rolle: Access-Device hat andere Control-Plane-Profile als Internet-Edge oder Core.
• Drop-Monitoring: Drops pro Klasse sind ein Security-Signal und ein Stabilitätsindikator.
• Change-Disziplin: Neue Protokolle (EVPN, SR, Telemetry) benötigen CoPP-Updates; ansonsten entstehen Self-DoS-Effekte.

Outbound-Referenzen

• Cisco: Control Plane Policing (CoPP) – Konzepte und Konfiguration als Cisco-orientierter Einstieg in Designprinzipien und Implementierung.
• Cisco: Access Lists – Best Practices als Grundlage für saubere Klassifizierung und Policy-Logik (wichtig für CoPP-ACLs).
• RFC 4861 (Neighbor Discovery) für RA/ND, die in CoPP nicht unbeabsichtigt gedrosselt werden dürfen.
• RFC 8201 (Path MTU Discovery for IPv6) als Begründung, warum ICMPv6 Packet Too Big funktional erforderlich ist.
• Cisco IOS XE Configuration Guides für plattformspezifische MQC/CoPP-Details, Syntax und Feature-Interaktionen.
• Cisco Nexus 9000 NX-OS Configuration Guides für NX-OS-spezifische Control-Plane-Protection-Mechanismen und Unterschiede im Datacenter-Umfeld.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.