Control Plane Policing (CoPP): CPU-Spikes im Fabric verhindern

Control Plane Policing (CoPP) ist eine der wirkungsvollsten Maßnahmen, um CPU-Spikes im Fabric zu verhindern und damit die Stabilität von Routing, EVPN/VXLAN, OAM und Management dauerhaft zu erhöhen. In modernen Spine-Leaf-Architekturen ist die Datenebene (ASIC) meist sehr robust und kann enorme Paketmengen weiterleiten – aber die Control Plane bleibt ein begrenzter, gemeinsam genutzter Ressourcenpool. Genau dort entstehen viele „mysteriöse“ Ausfälle: BGP-Sessions flappen, EVPN-Routen werden verspätet verarbeitet, OSPF/IS-IS konvergiert langsam, BFD meldet falsche Down-Events, oder Management-Zugriffe werden zäh. Häufig ist nicht ein einzelner Bug die Ursache, sondern eine Überlastung durch Pakete, die in die CPU „gepuntet“ werden: TTL-Expired, ARP/ND-Stürme, Broadcast-/Unknown-Unicast-Flooding, ungewollte Multicast-Ströme, fehlerhafte Hosts, Scans, oder schlicht ein Incident im Access, der sich bis zur Fabric-Control-Plane hochschaukelt. CoPP setzt genau an dieser Schnittstelle an: Es klassifiziert Control-Plane-relevanten Traffic (Routing, OAM, Management, Exceptions) und begrenzt ihn mit gezielten Policern, bevor er die CPU sättigt. Der entscheidende Punkt ist dabei operativ: CoPP ist kein „hartes Blocken“, sondern ein Balanceakt. Richtig umgesetzt verhindert CoPP CPU-Spikes im Fabric, ohne legitimen Control-Traffic zu kappen. Falsch umgesetzt erzeugt CoPP selbst Outages, weil essenzielle Protokolle gedroppt werden. Dieser Leitfaden erklärt CoPP praxisnah: was Sie schützen, welche Traffic-Klassen in Fabrics typischerweise die CPU belasten, wie Sie Policers sicher dimensionieren, wie Sie Rollout und Validierung durchführen und welche Telemetrie Pflicht ist, damit CoPP nicht zur Black Box wird.

Control Plane vs. Data Plane: Wo CPU-Spikes wirklich entstehen

Damit CoPP sinnvoll bleibt, muss zuerst klar sein, welche Pakete überhaupt die CPU erreichen. In typischen Switching-/Routing-Plattformen laufen „normale“ Forwarding-Entscheidungen im ASIC (Data Plane). Die CPU (Control Plane) verarbeitet dagegen Protokolle und Ausnahmen. Ausnahmen sind Frames, die der ASIC nicht vollständig in Hardware abhandeln kann oder bewusst an die CPU weiterleitet („punt“/„exception“). Genau diese Punt-Mechanismen werden bei Störungen zum Engpass.

• Data Plane: High-throughput Forwarding im ASIC; idealerweise kein CPU-Einfluss.
• Control Plane: Routing-Protokolle, EVPN-Control-Plane, Management, OAM, Control-Traffic.
• Punted/Exception Traffic: TTL-Expired, ARP/ND, bestimmte ICMP-Typen, Control Frames, „unknown“ oder „slow path“.

Warum CPU-Spikes im Fabric besonders kritisch sind

In einem Fabric hängen viele Funktionen indirekt an der Control Plane. Wenn sie überlastet ist, sieht das Netzwerk nicht nur „langsam“ aus, sondern wird logisch instabil. Besonders kritisch sind dabei Mechanismen mit strengen Timern:

• BFD/Keepalives: bei CPU-Delay entstehen False Positives (Links scheinbar down).
• BGP EVPN: Route-Processing wird verzögert, MAC/IP-Updates kommen zu spät.
• IGP: OSPF/IS-IS Konvergenz verlangsamt sich, ECMP-Pfade wechseln.
• Management/Automation: Telemetry und Konfig-Tools reagieren langsam oder verlieren Sessions.

Für Protokollgrundlagen können RFCs als Referenz dienen, etwa RFC 4271 (BGP), RFC 2328 (OSPFv2), RFC 5880 (BFD) und für ICMP RFC 792 (ICMPv4) bzw. RFC 4443 (ICMPv6).

Typische Auslöser für CPU-Spikes im Fabric

Bevor Sie Policers setzen, sollten Sie wissen, was in Ihrer Umgebung realistisch ist. Die häufigsten Auslöser lassen sich in wenige Kategorien einteilen.

Kategorie 1: L2-Stürme und Flooding aus dem Access

• Broadcast-Storm: ARP/DHCP/Discovery eskaliert; Storm-Control greift, aber ein Teil erreicht dennoch die CPU.
• L2-Loops: MAC-Flapping und BUM-Spikes erzeugen Exception-Traffic und Management-Overhead.
• MAC-Table-Thrashing: Unknown Unicast steigt, Geräte loggen/lernen aggressiv, CPU wird belastet.

Kategorie 2: Kontrollprotokolle und Timer-Sensitivität

• BGP Session Storm: viele Sessions flappen, Updates wiederholen sich, Routen werden neu berechnet.
• IGP Flooding: Topology Changes erzeugen LSA/LSP-Spikes.
• BFD False Down: CPU-Lag führt zu Cascade-Failover und weiteren Control-Plane-Events.

Kategorie 3: Punt-Events in der Datenebene

• TTL Expired: Traceroute- oder Scan-Traffic, der ICMP-Responses erzeugt.
• ARP/ND Peaks: insbesondere bei ARP/ND-Suppression-Problemen, Mobility, Failover oder großen Domains.
• Fragmentation/PMTUD-Anomalien: ICMP „Packet Too Big“/„Frag Needed“ kann CPU-lastig werden, wenn es massenhaft auftritt.

Kategorie 4: Management- und Telemetry-Last

• Zu aggressives Polling: SNMP/CLI-Scraping in zu kurzen Intervallen.
• Telemetry-Streams: gNMI/gRPC, sFlow/NetFlow/IPFIX Export oder Syslog-Spikes im Incident.
• Login-/Scan-Versuche: SSH/HTTPS/NETCONF werden durch Bots oder Fehlkonfigurationen belastet.

Was CoPP leistet: Schutz durch Klassifikation und Rate Limits

CoPP ist im Kern ein klassisches QoS-Prinzip für die CPU: Sie definieren Klassen (z. B. Routing kritisch, Management kritisch, ICMP begrenzt, „untrusted punt“ stark begrenzt) und weisen jeder Klasse eine erlaubte Rate zu. Wichtig ist: CoPP ist kein „alles oder nichts“. Sie gestalten mehrere Schutzschichten, damit ein Storm nicht Routing tötet und ein Scan nicht Management blockiert.

Policer-Grundprinzip (MathML)

$\mathrm{AllowedRate}=\mathrm{CIR}+\mathrm{Burst}$
$\mathrm{Drops}\Leftarrow \mathrm{IncomingRate}>\mathrm{AllowedRate}$

Operativ bedeutet das: Sie müssen CIR (Continuous Information Rate) und Burst so wählen, dass legitime Peaks (z. B. nach Failover) nicht sofort gekappt werden, während echte Stürme trotzdem schnell gebremst werden.

CoPP-Design: Die wichtigsten Traffic-Klassen im Fabric

Ein praxistaugliches CoPP-Design beginnt mit einer einfachen, robusten Klassifikation. Der konkrete Protokollmix variiert, aber diese Klassen haben sich als universell bewährt.

Klasse A: Kritische Routing- und Fabric-Control-Plane

• BGP/EVPN: Session-Management und Updates.
• IGP (OSPF/IS-IS): Underlay-Konnektivität und Konvergenz.
• BFD: schnelle Failure-Detection (wenn genutzt).

Diese Klasse darf nicht „zu knapp“ limitiert werden, weil sonst die Stabilität des gesamten Fabrics leidet. CoPP schützt diese Klasse idealerweise, indem andere Klassen stärker begrenzt werden, nicht indem man Routing selbst aggressiv deckelt.

Klasse B: Essenzielle L2/L3 Control Frames und Nachbarschaften

• ARP (IPv4) und ND (IPv6): notwendig für lokale Adjazenzen und EVPN-Edge-Funktionen.
• ICMP für PMTUD: relevante ICMP-Typen für „Packet Too Big“/„Frag Needed“ (gezielt erlauben, nicht pauschal).
• OAM/CFM (wenn eingesetzt): z. B. 802.1ag/Y.1731 auf L2-Services.

Hier ist die typische Pitfall-Zone: Zu strenge Limits erzeugen „mysteriöse“ Serviceprobleme (ARP timeouts, IPv6 instabil, MTU-Probleme unsichtbar). Zu lockere Limits lassen Storms durch.

Klasse C: Management und Automation

• SSH/HTTPS/API: Betrieb und Automatisierung.
• SNMP/gNMI/Telemetry: Monitoring und Observability.
• NTP/DNS (sofern am Gerät genutzt): Zeit und Namensauflösung für korrekte Logs.

Diese Klasse sollte priorisiert und getrennt werden, weil Management-Ausfall im Incident die Entstörung massiv verlängert. Gleichzeitig sollte die Rate so begrenzt sein, dass Login-/Scan-Versuche nicht die CPU fressen.

Klasse D: „Untrusted Punt“ und Noise

• TTL Expired/Traceroute-Noise: ICMP-Time-Exceeded kann bei Scans hochlaufen.
• Unknown/Unsupported Control Frames: Pakete, die nicht zu erwarteten Protokollen gehören.
• Fehlkonfiguration/Attack Patterns: random MAC/IP Floods, Control-Plane-Directed Scans.

Diese Klasse ist der Haupthebel für CPU-Spike-Prevention: Hier darf CoPP aggressiv sein, weil legitimer Bedarf selten ist. Das Ziel ist, dass ein Storm zwar sichtbar wird (Counters steigen), aber die CPU stabil bleibt.

Operative Pitfalls: So wird CoPP selbst zur Outage-Ursache

CoPP ist mächtig, aber riskant, wenn es ohne Baseline und ohne Validierung ausgerollt wird. Diese Fehler passieren besonders häufig:

• ARP/ND zu hart limitiert: führt zu sporadischem Host-Blackholing und „VLAN wirkt tot“.
• PMTUD-ICMP geblockt: verstärkt MTU-Probleme und erzeugt stille Drops.
• BGP/IGP zu knapp: Sessions flappen unter Last, Konvergenzzeiten steigen.
• Management nicht priorisiert: im Incident verlieren Sie Zugriff genau dann, wenn Sie ihn brauchen.
• Keine Burst-Toleranz: legitime Peaks nach Failover werden als „Storm“ behandelt.
• Keine Observability: Drops sind unsichtbar, weil Counters nicht gesammelt werden.

Tuning ohne legitimen Traffic zu kappen: Vorgehensmodell

Ein sicheres CoPP-Tuning beginnt nicht mit Zahlen, sondern mit Messung und schrittweiser Einführung. Das folgende Modell ist praxistauglich für Fabrics.

Schritt: Baseline erfassen

• CPU-Profil: CPU-Auslastung (P50/P95/P99) und Spike-Korrelation zu Events.
• Control-Plane Counters: punted packets nach Kategorie (ARP/ND, TTL, Routing, Management).
• Incident-Pattern: wann treten Peaks auf (Failover, Wartung, Access-Loops, Scan-Zeiten)?

Schritt: Klassen definieren und „Must-not-break“-Traffic markieren

• Must-not-break: BGP/IGP/BFD, essentielles Management, notwendige ICMP-Typen für PMTUD.
• Can-degrade: Traceroute/TTL Expired, seltene Discovery-Protokolle, untrusted punt.
• Can-drop: eindeutig unerwünschte oder nicht benötigte Protokolle an der Control Plane.

Schritt: Konservative Initialwerte setzen (staged rollout)

• Phase 1: Limits so hoch, dass nur extreme Stürme getroffen werden; Counters überwachen.
• Phase 2: Limits schrittweise an Baseline + Headroom anpassen.
• Phase 3: Feingranularität erhöhen (z. B. separate ICMP-Typen, separate Management-Kanäle).

Headroom-Logik (MathML)

$\mathrm{Limit}\approx \mathrm{P99}\left(\mathrm{legit\_rate}\right)+\mathrm{Headroom}$

Schritt: Validierung durch gezielte Tests

• Routing-Stabilität: BGP/IGP Sessions bleiben stabil, keine Timer-Timeouts.
• ARP/ND-Verhalten: Resolution stabil, keine Retries/Timeouts in repräsentativen Szenarien.
• PMTUD-Funktion: relevante ICMP-Typen werden nicht unabsichtlich gedroppt.
• Management-Resilienz: Zugriff bleibt unter Last möglich; Telemetry arbeitet ohne CPU-Spikes zu triggern.

Response-Plan: Wenn CoPP Drops im Incident sichtbar werden

Ein Vorteil von CoPP ist, dass es Incident-Symptome klarer macht: Statt CPU 100% und „alles flapped“ sehen Sie Counters in einer Klasse steigen. Ein Response-Plan sollte definieren, wie damit umzugehen ist.

• 1) Klasse identifizieren: welche CoPP-Klasse droppt? Routing, ARP/ND, TTL, Management?
• 2) Ursache eingrenzen: Access-Loop? MAC-Flood? Scan? Misconfiguration nach Change?
• 3) Ursache isolieren: Top-Talker-Port/Segment quarantänen, statt global Limits zu erhöhen.
• 4) Temporäre Anpassung: nur wenn zwingend, Limits moderat erhöhen und danach zurückführen.
• 5) Post-Incident: Baselines aktualisieren, CoPP-Klassen feinjustieren, Guardrails ergänzen.

Monitoring: Pflicht-Telemetrie, damit CoPP nicht zur Black Box wird

CoPP kann nur „sicher“ sein, wenn Sie wissen, was es droppt. Folgende Metriken sind im Fabric-Betrieb besonders wichtig:

• CPU (gesamt + nach Prozess): Trend und Spike-Korrelation.
• CoPP-Class Counters: matched/allowed/dropped pro Klasse, als Rate über Zeitfenster.
• Punt/Exception Counters: nach Ursache (ARP/ND, TTL, ICMP, unknown).
• Routing Health: BGP/IGP/BFD Flaps, Convergence-Zeiten.
• Access-Indikatoren: Broadcast/Unknown-Unicast Peaks, MAC move/churn, Storm-Control Hits.

Drop-Rate als KPI (MathML)

$\mathrm{DropRate}=\frac{\mathrm{dropped\_packets}}{\mathrm{time\_window}}$

Eine dauerhaft erhöhte DropRate in einer „kritischen“ Klasse ist ein sofortiges Signal, dass Limits zu eng sind oder dass ein dauerhafter Absenderfehler existiert, der isoliert werden muss.

Best Practices: CoPP in EVPN/VXLAN Fabrics

In EVPN/VXLAN-Umgebungen sind einige Punkte besonders wichtig, weil sich viele „mysteriöse“ Probleme genau hier konzentrieren:

• ARP/ND sorgfältig klassifizieren: nicht pauschal droppen; lieber baseline-basiert limitieren.
• ICMP für PMTUD gezielt erlauben: verhindert stille MTU-Drops (RFC 1191 für IPv4 PMTUD, RFC 8201 für IPv6 PMTUD).
• EVPN Control Plane schützen: BGP/EVPN in einer priorisierten Klasse, damit Route-Updates nicht verhungern.
• Untrusted Punt hart begrenzen: TTL-Expired/Scan-Noise und „unknown“ gehören in restriktive Klassen.
• Staged Rollout mit Guardrails: zuerst an einem Pod, dann ausrollen; immer mit klarer Rollback-Option.

Evidence Pack: Pflichtdaten für CPU-Spikes und CoPP-Änderungen

Damit CoPP-Änderungen nachvollziehbar bleiben und RCAs nicht spekulativ sind, sollten Sie bei jedem CPU-Spike und bei jeder CoPP-Anpassung ein schlankes Evidence Pack erstellen:

• Zeitfenster (UTC): Start, Peak, Mitigation, Stabilitätsfenster.
• CPU-Telemetrie: Verlauf, ggf. Prozess-/Thread-Top.
• CoPP-Counters: matched/allowed/dropped pro Klasse als Zeitreihe.
• Punt-Quellen: Top Gründe (ARP/ND, TTL, ICMP, unknown) und Top Ports/VRFs/Segmente, wenn verfügbar.
• Routing-Impact: BGP/IGP/BFD Flaps, Convergence-Zeit, EVPN Route Processing Indizien.
• Access-Korrelation: Broadcast/Unknown-Unicast Peaks, MAC-Flapping, Storm-Control Hits.
• Change-Diff: welche Policers/ACLs wurden geändert, inklusive Rollback.

Outbound-Ressourcen

• RFC 4271 (BGP)
• RFC 5880 (BFD)
• RFC 792 (ICMPv4)
• RFC 4443 (ICMPv6)
• RFC 7432 (EVPN)
• RFC 7348 (VXLAN)
• RFC 1191 (Path MTU Discovery IPv4)
• RFC 8201 (Path MTU Discovery IPv6)

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.