Control Plane Policing Debugging: CoPP greift zu hart (oder gar nicht)

Control Plane Policing Debugging ist eine der wichtigsten, aber zugleich frustrierendsten Aufgaben im Betrieb moderner Router und Switches: CoPP (Control Plane Policing) soll die Control Plane schützen, damit Routing-Protokolle, ARP/ND, Management und Exception-Handling auch unter Stress zuverlässig funktionieren. In der Praxis passiert jedoch häufig das Gegenteil: CoPP greift zu hart, schneidet legitimen Traffic ab und verursacht genau die Instabilität, die es verhindern sollte – BGP-Sessions flappen, OSPF-Adjazenzen resetten, ARP-Auflösung wird langsam, SNMP/gNMI timeouten, oder SSH reagiert zäh. Umgekehrt kann CoPP auch „gar nicht“ greifen, wenn Klassifizierer falsch matchen oder wenn bestimmte Punt-Pfade nicht abgedeckt sind; dann wird die CPU von punted Traffic überrollt und das Gerät wird unbedienbar. Professionelles Control Plane Policing Debugging bedeutet deshalb: CoPP nicht als starre Policy betrachten, sondern als präzises Schutzsystem, das mit Beweisen kalibriert werden muss. Dieser Artikel zeigt eine praxiserprobte Methodik, um zu beweisen, ob CoPP zu hart oder zu lax ist, wie Sie die richtigen Klassen identifizieren, wie Sie Drops korrekt interpretieren und wie Sie Mitigationen wählen, die die Control Plane stabilisieren, ohne eine Sicherheitslücke zu reißen.

Mentales Modell: Data Plane, Punt-Path und Control Plane

Damit CoPP-Debugging nicht zum Ratespiel wird, müssen Sie den Weg eines Pakets im Gerät grob verstehen. Die meisten Pakete werden in der Data Plane (ASIC/Fast Path) weitergeleitet. Bestimmte Pakete werden jedoch „gepuntet“ (an die CPU/Control Plane übergeben), weil sie eine Ausnahme darstellen oder weil sie die Control Plane adressieren. Genau diese Punt-Pfade sind das Spielfeld von CoPP.

• Data Plane: Forwarding ohne CPU-Beteiligung, solange der Traffic normal und in Hardware abbildbar ist.
• Punt/Exception Path: Pakete, die nicht in Hardware behandelt werden können oder eine CPU-Aktion erfordern (z. B. TTL expired, ARP, bestimmte ICMP-Typen, Control-Protokolle).
• Control Plane: CPU verarbeitet Routing, Neighbor-Events, Management-Services, und erzeugt ggf. Antworten (z. B. ICMP).

CoPP sitzt logisch vor der Control Plane und entscheidet: Welche punted/Control-Plane-Pakete dürfen durch, welche werden rate-limited oder gedroppt? Das Ziel ist nicht „alles erlauben“, sondern „kritische Funktionen zuverlässig halten“.

Warum CoPP zu hart greift: Die häufigsten Ursachen

Wenn CoPP legitime Pakete verwirft, sind die Symptome oft intermittent: Protokolle flappen nur unter Last, ARP/ND hängt nur sporadisch, oder Management wird nur zeitweise langsam. Typische Ursachen liegen fast immer in einer von vier Kategorien.

• Zu niedrige Policers: Default- oder „Security-harte“ Raten sind für reale Last (z. B. ARP/ND bei Host-Churn) zu klein.
• Falsche Klassifizierung: Kritischer Traffic wird in die falsche Klasse gematcht (z. B. Routing-Hellos landen in einer generischen ICMP/Other-Klasse).
• Asymmetrie und Topologie-Effekte: Ein Gerät wird zum Hotspot für Control Traffic (z. B. Anycast-GW, zentraler Resolver, Gateway für viele VRFs) – CoPP war auf weniger Scope ausgelegt.
• Neue Features/Änderungen: Telemetrie, neue VRFs, neue ACLs oder neue Security-Funktionen ändern Punt-Verhalten, ohne dass CoPP angepasst wurde.

Warum CoPP „gar nicht“ greift: Die häufigsten Ursachen

Das gegenteilige Problem ist genauso gefährlich: CoPP existiert, aber schützt nicht. Dann sehen Sie CPU-Spikes, Control-Plane-Overload und im schlimmsten Fall Routing-Blackouts. Ursachen sind häufig subtil:

• Unvollständige Abdeckung: Nicht alle Punt-Reasons oder Control-Protokolle sind klassifiziert; „Default“ erlaubt zu viel.
• Falsche Reihenfolge/Priorität: Eine breite Permit-Klasse matcht vor der restriktiven Klasse; die strenge Policy greift nie.
• Falsches Attachment: CoPP ist auf dem falschen Control-Plane-Interface/Context angewendet oder in einem falschen VRF-Context.
• Hardware-/Software-Spezifika: Bestimmte Punt-Pfade umgehen die übliche CoPP-Policy (plattformabhängig) oder werden anders gezählt.

High-Signal Symptome: Woran Sie CoPP-Probleme schnell erkennen

CoPP-Probleme sind in Logs und Metriken oft klar erkennbar, wenn Sie wissen, wo Sie hinschauen müssen. Die wichtigsten Symptome sind „Protokollinstabilität unter Last“ und „Management-/Control-Funktionen brechen zuerst“.

• Routing-Flaps: BGP Neighbor resets, OSPF adjacency down/up, IS-IS adjacency issues – oft zeitlich korreliert mit CoPP drops.
• Neighbor-Probleme: ARP/ND timeouts, Duplicate-IP-Meldungen, Host reachability sporadisch.
• ICMP-Anomalien: Traceroute/Ping wird unzuverlässig, während Datenpfad noch funktioniert (oder umgekehrt).
• Management degradations: SSH/CLI zäh, SNMP timeouts, Telemetry gaps, Syslog wird lückenhaft.
• CPU-Spikes und Interrupt-Last: wenn CoPP nicht schützt oder wenn zu viel punted Traffic die CPU erreicht.

Wichtig: CoPP kann Probleme verursachen, ohne dass die CPU hoch ist. Wenn CoPP zu hart droppt, bleibt die CPU oft „gesund“, aber kritische Control-Pakete werden verworfen.

Beweisführung: CoPP greift zu hart oder gar nicht?

Eine belastbare Diagnose entsteht, wenn Sie drei Fragen beantworten: Welche Klasse droppt? Welcher Traffic steckt dahinter? Und welche Funktion ist dadurch beeinträchtigt? Die Reihenfolge ist entscheidend: erst Klassen/Drops, dann Traffic-Identität, dann Impact-Korrelation.

Schritt 1: Drops pro Klasse und Zeitfenster

• Welche Klasse droppt? ARP/ND, Routing-Protokolle, ICMP, Management, „Default“.
• Wie stark? absolute Drops und Rate (Drops/s), nicht nur „Counter steigt“.
• Wann? Korrelation mit Incident-Zeitpunkt, nicht mit „irgendwann heute“.

Schritt 2: Traffic-Identität über Punt-Reasons und Protokollsignaturen

Viele Plattformen bieten Zähler nach Punt-Reason (z. B. TTL expired, ARP, glean, control protocol). Diese Zähler sind häufig der schnellste Weg, um zu beweisen, ob die CPU wirklich „falschen“ Traffic sieht oder ob ein Protokollstorm vorliegt. Ergänzend hilft Flow-Telemetrie (NetFlow/IPFIX oder sFlow), um Quellen und Ziele zu erkennen.

• Punt-Reason Counters: Beweisen „warum zur CPU“ (z. B. ARP storm, TTL-expired flood).
• Flow Telemetry: Beweist „wer/wo“ (Top Talkers, PPS, viele kurze Flows). IPFIX-Referenz: RFC 7011.
• Logs/Syslog: Beweisen „was“ (Neighbor flaps, BGP resets, CoPP drop messages). Syslog-Referenz: RFC 5424.

Schritt 3: Impact-Korrelation mit Protokollzuständen

Der entscheidende Nachweis ist die Kette: CoPP-Drops steigen → Protokollzustand kippt. Bei BGP und OSPF sind die zugrundeliegenden Mechaniken standardisiert: BGP nutzt Keepalive/Hold-Timer (RFC 4271), OSPF nutzt Hello/Dead-Intervalle (RFC 2328). Wenn CoPP genau diese Control-Pakete droppt, sind Flaps eine logische Folge, nicht „mysteriös“.

Die häufigsten Traffic-Klassen, die CoPP falsch trifft

In der Praxis gibt es einige wiederkehrende „Problemkandidaten“, bei denen CoPP entweder zu restriktiv oder zu breit ist.

ARP und IPv6 Neighbor Discovery

• Warum kritisch? Ohne ARP/ND können neue Flows nicht entstehen; bestehende können sporadisch brechen, wenn Neighbor Entries auslaufen.
• Warum droppt CoPP hier oft zu hart? ARP/ND-Raten können bei Host-Churn, VM-Migration, L2-Instabilität oder Duplicate IPs explodieren.
• Mitigation-Ansatz: Policer an reale Spitzen anpassen, gleichzeitig Root Cause (L2-Loop, Duplicate IP, zu große Broadcast-Domäne) beheben.

ICMP und TTL-expired

• Warum kritisch? ICMP ist Diagnose- und Control-Mechanik (PMTUD, unreachable, time exceeded).
• Warum gefährlich? Traceroute- oder Scan-Stürme können ICMP-Generierung triggern und CPU belasten; zu harte CoPP-ICMP-Policer können PMTUD brechen („klein geht, groß nicht“).
• PMTUD-Kontext: ICMP „Fragmentation Needed“ und „Packet Too Big“ sind zentral für PMTUD; Referenzen: RFC 1191 und RFC 8201.

Routing-Protokolle (BGP, OSPF, IS-IS)

• Warum kritisch? Keepalives/Hellos sind klein, aber zeitkritisch. Drops verursachen Flaps.
• Warum trifft CoPP hier manchmal gar nicht? Wenn die Klassifizierung nur auf Ports/Protokolle achtet, aber Control Traffic über andere Interfaces/VRFs oder via tunneling ankommt.
• Mitigation-Ansatz: Klare Klassen für Routing-Protokolle, konservative Policers, separate Behandlung für peering vs. internal.

Management Traffic (SSH, SNMP, gNMI)

• Warum kritisch? Im Incident ist Management Ihr Diagnosewerkzeug.
• Warum wird es gedroppt? Management wird oft mit „low priority“ behandelt oder teilt sich eine generische Klasse mit anderem Traffic.
• Mitigation-Ansatz: Management-Plane segmentieren (Out-of-Band), CoPP-Klasse für mgmt strikt, aber ausreichend dimensioniert, und Polling/Telemetry kuratieren.

Debugging-Methodik: Von „Drops“ zur konkreten Ursache

Das Ziel ist, den Verursacher zu finden, nicht nur die Policy zu ändern. Eine robuste Methodik arbeitet immer in zwei Richtungen: CoPP-Policy kalibrieren und gleichzeitig den Traffic-Auslöser (Storm, Scan, Loop, Misconfig) identifizieren.

• Top-Down: Start bei CoPP-Klassen → welche Klasse droppt → welche Protokolle gehören dazu → welche Funktion leidet.
• Bottom-Up: Start bei Symptom (BGP flaps, ARP timeouts) → welches Protokoll ist betroffen → welche CoPP-Klasse sollte es schützen → warum wird es gedroppt oder nicht geschützt.

Gezielte Verifikation: Captures und „Follow the Packet“

Wenn Sie den Inhalt des punted Traffics belegen müssen, sind gezielte Packet Captures hilfreich. Wichtig ist, nicht „alles“ zu spiegeln, sondern nur die relevanten Control-Plane-Flows und die Verdächtigen (z. B. ARP/ND, ICMP, Routing-Protokollpakete). In vielen Umgebungen funktioniert das über SPAN/ERSPAN am Uplink oder über tcpdump auf einem Collector, der Mirror-Traffic empfängt. Referenzen: tcpdump Manpage und Wireshark Dokumentation.

• Beweisziel: Welche Pakete kommen in hoher Rate an? Welche Quellen? Welche Protokolle?
• Beweisziel: Gibt es scanningartige Muster (viele Ziele/Ports) oder loopartige Muster (Broadcast/ARP flood)?
• Mehrpunkt-Ansatz: Bei komplexen Netzen kann ein zweiter Messpunkt (vor/nach Firewall) beweisen, ob Traffic extern oder intern erzeugt wird.

Mitigation: CoPP entschärfen, ohne die Control Plane zu öffnen

Wenn CoPP zu hart greift, ist der Reflex oft „Policer hochsetzen“. Das kann richtig sein, ist aber riskant, wenn der eigentliche Auslöser ein Storm oder Angriff ist. Eine gute Mitigation kombiniert kurzfristige Stabilisierung mit einer Begrenzung der Angriffsfläche.

• Policer gezielt anheben: Nur für die betroffene legitime Klasse (z. B. ARP/ND), nicht pauschal im Default.
• Separate Klassen schärfen: Kritische Protokolle (Routing, ARP/ND) klar trennen von „Other“.
• Ingress-Filter vor CoPP: Wenn möglich, Quellenbegrenzung per ACL an Edge-Interfaces (z. B. nur erlaubte Peers für BGP/OSPF, Management nur aus Admin-Netzen).
• Storm-Ursache beheben: L2-Loops, Duplicate IPs, scanning Hosts isolieren; CoPP ist Schutz, nicht Heilung.
• Management entlasten: Telemetry/ SNMP-Last reduzieren, damit CoPP nicht zum Flaschenhals für Diagnose wird.

Wenn CoPP zu lax ist: Schutz nachrüsten ohne Kollateralschäden

Wenn CoPP nicht greift, ist die Gefahr, dass die CPU überrollt wird. Hier ist „harter“ Schutz oft nötig, aber mit sauberer Klassifizierung und Baselines, sonst schießen Sie sich Routing und ARP selbst ab.

• Baselines messen: Normale Raten für ARP/ND, Routing-Hellos, ICMP Errors, Management. Erst dann Policer festlegen.
• Default nicht „wide open“: Eine restriktive Default-Klasse ist sinnvoll, solange kritische Klassen korrekt abgedeckt sind.
• Peering-Klassen: BGP/OSPF/IS-IS für bekannte Peers separieren; alles andere rate-limit.
• ICMP differenzieren: PMTUD-relevante ICMP-Typen nicht gleich behandeln wie TTL-expired floods.

Observability für CoPP: Damit Sie nicht erst im Incident lernen

CoPP ist am besten, wenn es kontinuierlich überwacht wird. Dafür brauchen Sie Metriken, die nicht nur CPU zeigen, sondern Drops pro Klasse und Punt-Reasons. Ergänzend helfen Syslog-Korrelationen und Flow-Telemetrie, um Auslöser zu identifizieren.

• KPIs: Drops/s pro CoPP-Klasse, Punt-rate pro Reason, CPU user/system/interrupt, Routing neighbor state changes.
• Baselines: Tagesmuster für ARP/ND und Control-Plane-Events. Ohne Baseline wirken legitime Peaks wie Angriffe.
• Korrelation: Drops in einer Klasse + Protokollflaps + Zeitfenster = starke Beweiskette.

Runbook-Baustein: CoPP Debugging in 15 Minuten

• Minute 0–3: Symptom klassifizieren (BGP/OSPF flaps, ARP/ND timeouts, Management down, ICMP/PMTUD Probleme). Zeitfenster festlegen.
• Minute 3–6: CoPP/CPPr Stats prüfen: Drops pro Klasse, Rate, welche Klassen steigen im Incident. CPU prüfen, aber nicht als alleinige Wahrheit.
• Minute 6–9: Punt-Reasons/Traffic-Identität eingrenzen: ARP/ND, TTL-expired, routing protocol, mgmt. Flow Telemetry nutzen, um Top Talkers/PPS-Spikes zu finden.
• Minute 9–12: Impact-Korrelation: Protokollzustände (BGP/OSPF) und Logs gegen CoPP-Drops legen. Prüfen, ob CoPP zu hart (Drops steigen, CPU ok) oder zu lax (CPU hoch, Drops fehlen) ist.
• Minute 12–15: Mitigation wählen: gezielt Policers anpassen, Klassen trennen, Ingress-ACLs schärfen, Auslöser isolieren. Danach verifizieren: Drops sinken oder werden sinnvoll verteilt, Protokolle stabilisieren, Management wird wieder zuverlässig.

Weiterführende Quellen

• RFC 4271 für BGP-Session-Mechanik (Keepalive/Hold-Time) und warum CoPP-Drops Sessions flappen lassen
• RFC 2328 für OSPFv2 (Hello/Dead Timer) als Grundlage für Triage bei Adjazenzproblemen
• RFC 1191 und RFC 8201 für PMTUD (ICMP-Typen, die CoPP nicht „aus Versehen“ kaputtpolicen sollte)
• RFC 7011 für IPFIX/Flow Telemetry zur schnellen Identifikation von Verursachern
• RFC 5424 für Syslog-Strukturierung, damit CoPP-Events und Protokollflaps sauber korrelierbar werden
• tcpdump Manpage und Wireshark Dokumentation für gezielte Captures zur Beweisführung bei punted/Control-Plane-Traffic

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.