High CPU auf Netzwerkgeräten: Control Plane Overload nachweisen

High CPU auf Netzwerkgeräten ist eines der tückischsten Fehlerbilder im Betrieb, weil es sich selten wie ein „klassischer“ Link-Ausfall anfühlt. Stattdessen sehen Sie Symptome, die überall und nirgendwo auftreten: BGP-Sessions flappen, OSPF-Adjazenzen werden instabil, SNMP/Telemetry hat Lücken, CLI reagiert zäh, einzelne Flows timeouten, ARP/ND-Auflösung wird langsam, und manchmal wirkt das Gerät plötzlich „wie eingefroren“. In vielen Fällen lautet die vorschnelle Diagnose: „Der Router ist überlastet.“ Das ist zu grob und führt oft zu falschen Maßnahmen. Entscheidend ist, ob es sich um echte Control Plane Overload handelt – also eine Überlast der CPU durch punted Traffic, Protokoll-Stürme, Ausnahmebehandlungen oder Softwarepfade – oder um etwas anderes: z. B. Data Plane Congestion, Management-Plane Flooding, Telemetrie-Overhead oder sogar einen Softwarebug. Dieses Troubleshooting erfordert eine saubere Beweisführung: Welche CPU (Routing-Engine, Supervisor, Linecard-CPU) ist hoch? Welche Prozesse dominieren? Welche Pakete werden zur CPU gepuntet und warum? Welche Schutzmechanismen greifen (CoPP/CPPr/Policers)? Und wie korreliert das alles zeitlich mit den Impact-Symptomen? Dieser Artikel zeigt eine praxistaugliche Methodik, um Control Plane Overload nachzuweisen und schnell zur wahrscheinlichsten Root Cause zu kommen.

Control Plane, Data Plane, Management Plane: Erst trennen, dann messen

Bevor Sie in Countern und Logs versinken, brauchen Sie ein klares Modell. Viele „High CPU“-Incidents sind eigentlich Missverständnisse darüber, welche Ebene betroffen ist.

• Data Plane: ASIC/NP/Forwarding – hier laufen die meisten Pakete im Fast Path. Hohe Auslastung in der Data Plane zeigt sich eher als Congestion (Queues, Drops), nicht als CPU-100%.
• Control Plane: Routing-Protokolle, ARP/ND, ICMP für Exceptions, L2-Control (STP/LACP), FIB/RIB-Updates – oft CPU-getrieben.
• Management Plane: SSH/CLI, SNMP, gNMI, Syslog, Netconf/REST, Telemetry-Agenten – kann CPU und Speicher stark belasten, ohne dass Forwarding selbst kaputt ist.

High CPU ist erst dann eine Control Plane Overload, wenn die CPU durch control-plane-relevante Verarbeitung oder punted/exception Traffic ausgelastet wird und dadurch control-plane-Funktionen oder Forwarding-Entscheidungen beeinträchtigt werden.

Warum Control Plane Overload so viele Symptome erzeugt

Die CPU ist in Netzwerkgeräten oft ein gemeinsamer Engpass für sehr unterschiedliche Aufgaben. Wenn sie überlastet ist, konkurrieren Protokoll-Threads, Punt-Queues, Timer-Wheels und Management-Dienste um Zeit. Typische Folgeeffekte:

• Routing-Protokolle werden instabil: Keepalives/Hellos kommen verspätet, Dead-Timer laufen ab, Sessions resetten.
• ARP/ND wird langsam: Neue Flows können nicht aufgebaut werden, weil Neighbor Resolution hängt.
• Control-Plane-Policer greifen: Pakete zur CPU werden gedroppt – scheinbar „random“, aber oft deterministisch nach Klasse.
• Monitoring wird blind: SNMP/Telemetry timeouts, Syslog-Lücken, weil Management-Plane nicht mehr bedient wird.
• CLI/SSH wird unbrauchbar: Gerade im Incident ist das fatal, weil Diagnosewerkzeuge wegbrechen.

Beweisfrage definieren: „Warum ist CPU hoch?“ statt „CPU ist hoch“

Im Incident ist die CPU-Zahl nur der Startpunkt. Die eigentliche Beweisfrage lautet: Welche Quelle treibt die CPU, und über welchen Pfad? Eine robuste Beweisführung folgt einem festen Raster:

• Was ist hoch? Gesamt-CPU, einzelne Core(s), Routing Engine, Linecard CPU, Interrupt-Rate?
• Wer ist hoch? Welche Prozesse/Threads dominieren (Routing, ARP, telemetryd, snmpd, kernel softirq)?
• Warum zur CPU? Welche Pakete/Events wurden gepuntet (exceptions) oder erzeugen Protokollarbeit?
• Welche Schutzschicht greift? CoPP/CPPr, rate-limits, hardware punts, punt queues.
• Was ist der Impact? Welche Funktion fällt zuerst aus (BGP, OSPF, ARP, Management)?

Typische Root Causes für High CPU auf Netzwerkgeräten

In der Praxis wiederholen sich Ursachenmuster. Wenn Sie sie kennen, verkürzt sich Ihre Triage dramatisch.

Punted Traffic und Exceptions

• TTL Expired / Traceroute-Stürme: Viele TTL-expired Pakete werden zur CPU gepuntet, weil ICMP Time Exceeded erzeugt werden muss.
• Fragmentation/PMTUD ICMP Handling: ICMP-Generierung oder -Verarbeitung kann CPU kosten, besonders bei Fehlkonfigurationen.
• ARP/ND Flood: Viele neue Neighbors, Duplicate IPs, ARP Flux, ND Storms – CPU wird mit Neighbor-Events überflutet.
• Control-Plane-Targeted Traffic: UDP/123 (NTP), UDP/161 (SNMP), BGP/179, OSPF/89 – wenn exponiert, kann das schnell eskalieren.

Routing Instabilität und Control-Plane Churn

• BGP Route Churn: viele Updates, Flaps, Policy-Recompute, RIB/FIB Pressure.
• IGP Flooding: LSP/LSA Stürme bei IS-IS/OSPF, häufig ausgelöst durch Link flaps oder falsch gesetzte Timers.
• Recursive Resolution/Next-Hop Instabilität: Next-Hop wechselt, ECMP-Set ändert sich, FIB Updates laufen heiß.

Layer-2 Kontrollstürme

• STP TCN Storms: Topology Changes erhöhen Control Traffic und MAC-Table Updates.
• MAC Flapping: führt zu massiven CAM/MAC-Table Updates, teils CPU-lastig, je nach Plattform.
• LACP Churn: Member raus/rein, MLAG/vPC Instabilität – erzeugt Events und Rehashing.

Management-Plane Overload

• Zu aggressive Telemetrie: hohe Frequenz, zu viele Pfade (gNMI), zu große SNMP Walks.
• Log-Stürme: Syslog in hoher Rate, Debug-Logs aktiviert, event storms.
• Automations-Spikes: gleichzeitige Config Pushes, wiederholte Polling-Jobs, Inventory-Scans.

Software-/Plattform-Bugs

• Memory Leak / Prozess hängt: CPU dauerhaft hoch, auch ohne Traffic-Anomalie.
• Interrupt/Softirq Bugs: CPU hoch im Kernel-Context, oft zusammen mit bestimmten Interface-Typen oder Offload-Features.
• Telemetry/Agent Bugs: telemetryd, snmpd oder mgmt-Prozesse laufen heiß.

High-Signal Datenquellen: Was Sie im Incident zuerst holen sollten

Sie brauchen wenige, aber aussagekräftige Signale. Priorisieren Sie Daten, die Ursache und Pfad sichtbar machen.

• CPU Breakdown: user/system/interrupt, pro Prozess, pro Core, pro Supervisor/RE/Linecard.
• Punt/Exception Counters: wie viele Pakete werden zur CPU gepuntet, welche Gründe (TTL, ARP, ACL, unknown unicast, control protocols)?
• CoPP/CPPr Stats: drops/permits pro Klasse – zeigt, welche Control-Plane-Klasse überläuft.
• Protocol Health: BGP neighbor state changes, OSPF/IS-IS adjacency events, LACP/STP events.
• Interface/Queue Indicators: nicht als Ursache für CPU, aber zur Abgrenzung (Congestion vs. CPU): Discards/Drops, queue occupancy.
• Flow Telemetry: Top Talkers, PPS-Spikes, viele kurze Flows, ungewöhnliche Zielports – oft der schnellste Weg, den Verursacher zu finden.

Control Plane Overload beweisen: Drei Beweiswege, die zuverlässig funktionieren

Beweisweg 1: Prozessdominanz plus korrelierter Impact

Wenn ein oder wenige Prozesse die CPU dominieren, ist das ein starkes Indiz. Entscheidend ist die Korrelation: Steigt die CPU gleichzeitig mit Routing-Flaps, ARP-Problemen oder Management-Timeouts? Dann ist die Ursache wahrscheinlich in dieser Prozessdomäne.

• Routing-Prozess dominiert: Route churn, policy recompute, IGP flooding wahrscheinlich.
• ARP/ND-Prozess dominiert: L2/L3 Neighbor-Events, Duplicate IP, ND storm wahrscheinlich.
• snmpd/telemetryd dominiert: Management-Overload, Polling/Telemetry zu aggressiv.
• Kernel/interrupt dominiert: punt storms, interface/driver issues oder extreme PPS.

Beweisweg 2: Punt/Exception-Zähler und CoPP-Drops

Der sauberste Nachweis für Control-Plane-Traffic-Probleme ist: Punt-Zähler steigen, CoPP-Drops steigen, und die CPU geht hoch. Wenn Sie zusätzlich sehen, welche Klasse gedroppt wird (z. B. ARP, ICMP, routing protocol), haben Sie nicht nur „CPU hoch“, sondern „CPU hoch durch Klasse X“.

• ICMP/TTL class drops: traceroute/TTL expired storms oder scanning.
• ARP/ND class drops: neighbor flood, duplicate IP, L2 loop-bedingte Broadcasts.
• Routing protocol class drops: adjacency instabil, neighbors verlieren hellos/keepalives.
• Management class drops: SNMP/SSH timeouts, NMS wirkt blind.

Beweisweg 3: Traffic-Muster (Flows) und Zielgerichtete Captures

Wenn Sie den Traffic-Verursacher identifizieren müssen, sind Flows (NetFlow/IPFIX oder sFlow) oft schneller als PCAPs. Sie zeigen, wer viele Pakete oder viele kurze Flows erzeugt. Danach können Sie gezielt capturen – idealerweise an einem Punkt, der den punt/relevanten control-plane traffic sieht (z. B. auf dem Interface vor dem Gerät oder auf einem Mirror-Port).

• Flow-Rate-Spike: viele kurze Flows → state pressure, punt storms, control-plane policing.
• PPS-Heavy Talker: ein Host erzeugt extrem PPS (Scan, Misconfig, Loop).
• Ungewöhnliche Ziele: viele Pakete an die Router-IP oder an control-plane ports (SNMP, BGP, NTP).

Die häufigsten „CPU hoch“ Fehlerbilder im Detail

ARP/ND Storm und Duplicate IP

ARP- und ND-Stürme sind Klassiker: Ein L2-Loop, ein falsch konfigurierter Host oder Duplicate IPs erzeugen ständig Neighbor-Events. Das triggert CPU-Last und kann neue Verbindungen unbrauchbar machen. High-Signal Indikatoren sind schnelle Zunahme von ARP/ND Countern, syslog mit duplicate address, sowie CoPP drops in der ARP/ND-Klasse.

• Nachweis: ARP/ND rate hoch, CPU hoch, neighbor table churn.
• Mitigation: ARP inspection/ND inspection, storm control, duplicate IP isolieren, L2 loop beheben.

Traceroute/TTL Expired und ICMP Overload

Wenn viele Pakete mit niedriger TTL das Gerät erreichen (oder wenn traceroute-flooding stattfindet), muss das Gerät ICMP Time Exceeded erzeugen. Das ist CPU-intensiv und führt zu ICMP/TTL class drops. Besonders tückisch: Der Angriff/Scan ist oft „unauffällig“ im Mbps, aber sehr hoch im PPS.

• Nachweis: punt reason TTL expired hoch, ICMP generation, CoPP ICMP drops, CPU in interrupt/system.
• Mitigation: CoPP feinjustieren, rate-limits, ingress ACLs, source begrenzen.

Routing Churn: BGP/IGP Updates und Policy-Recompute

Routing-Instabilität ist ein CPU-Verstärker: Link flaps oder policy changes führen zu vielen Updates, die RIB/FIB reprogrammieren. Symptome sind BGP flap storms, OSPF adjacency resets, steigende convergence time, und CPU-lastige Routing-Prozesse.

• Nachweis: neighbor resets korrelieren mit CPU peaks, update counters hoch, route flap logs.
• Mitigation: flap-damping (vorsichtig), timer tuning, policy simplifizieren, route limits/max-prefix, root cause link flaps beheben.

Management Overload: SNMP, Telemetry und Automations

Viele Umgebungen poll’n zu aggressiv: SNMP walks über große Tabellen, Telemetrie-Subscriptions mit hoher Frequenz auf zu vielen Pfaden, oder gleichzeitige Automations-Jobs. Das kann CPU und Speicher stark belasten, ohne dass die Data Plane „schuld“ ist.

• Nachweis: mgmt-Prozesse dominieren CPU; spikes korrelieren mit NMS/automation schedules.
• Mitigation: Polling reduzieren, caching, sampling, subscriptions kuratieren, mgmt-plane rate-limits, out-of-band mgmt.

Abgrenzung: Wann High CPU nicht die Ursache ist

Es gibt zwei gefährliche Fehlinterpretationen: (1) CPU ist hoch, also ist sie Ursache; (2) CPU ist niedrig, also ist es kein Control-Plane-Problem. Beides kann falsch sein.

• CPU hoch als Folge: Ein Link flap erzeugt routing churn; CPU steigt nur, weil das Gerät reagiert. Root Cause ist physisch (Optics/LACP), nicht CPU.
• CPU niedrig trotz Impact: CoPP droppt schon früh – die CPU bleibt „ok“, aber control-plane traffic wird verworfen. Impact entsteht durch Policer, nicht durch CPU-100%.
• Data Plane Congestion: Hohe Drops/Discards in egress queues verursachen Latenz/Loss; CPU ist Nebensache.

Telemetry-Design: Damit Sie Control Plane Overload früh sehen

Der beste Zeitpunkt, High CPU zu debuggen, ist bevor das Gerät unbedienbar wird. Dafür brauchen Sie kuratierte Telemetrie, die nicht selbst die Management-Plane überlastet.

• High-Signal KPIs: CPU total + per Prozess, punt counters, CoPP drops pro Klasse, routing neighbor states, ARP/ND rates.
• Frequenz intelligent wählen: Hotspots (Internet edge, DC spine) häufiger; Access weniger häufig.
• Logs dedupen: Event storms (link flaps, neighbor changes) zusammenfassen, statt tausende Zeilen zu speichern.
• Baseline-Ansatz: Was ist normale CPU am Gerätetyp? Was ist normaler punt-rate? Ohne Baseline ist jeder Peak „subjektiv“.

Gezielte Verifikation: Packet Capture und „Follow the Packet“

Wenn Sie beweisen müssen, welche Pakete zur CPU gelangen oder welche control-plane traffic class eskaliert, sind gezielte Captures hilfreich. In Produktionsnetzen funktioniert das am besten mit SPAN/ERSPAN oder Ring-Buffer-Captures auf einem Collector, der nur den relevanten Flow sieht. Für Tooling sind die tcpdump Manpage und die Wireshark Dokumentation praktische Referenzen.

• Capture-Frage: Sehen wir TTL-expired, ARP storm, ICMP flood, oder ungewöhnliche mgmt traffic patterns?
• Mehrpunkt-Capture: Wenn möglich, vor und nach einer Firewall/Edge capturen, um zu beweisen, ob traffic eingehend ist oder intern generiert wird.
• Datenschutz: Snaplen reduzieren und Filter eng setzen, um Payload zu minimieren.

Mitigation ohne Blindflug: Stabilisieren und gleichzeitig Beweise sichern

In einem echten Incident müssen Sie oft schnell stabilisieren, auch wenn die RCA noch nicht fertig ist. Wichtig ist, Maßnahmen zu wählen, die den Impact reduzieren und die Ursache nicht verschleiern.

• CoPP/Policer aktivieren oder schärfen: schützt die Control Plane, kann aber Symptome ändern. Dokumentieren Sie Zeitpunkt und Effekt.
• Traffic-Quelle isolieren: Wenn ein Host/Segment punt storms erzeugt, temporär blocken oder rate-limiten.
• Routing dämpfen (vorsichtig): max-prefix, dampening, policy simplifizieren – nur, wenn Route churn eindeutig ist.
• Management-Load reduzieren: Telemetry/ SNMP-Intervalle temporär erhöhen, große Walks stoppen, debug logs deaktivieren.
• Failover/Traffic Shift: wenn möglich, Traffic vom betroffenen Gerät wegnehmen, um Diagnose zu ermöglichen.

Runbook-Baustein: High CPU und Control Plane Overload in 15 Minuten nachweisen

• Minute 0–3: CPU-Problem klassifizieren: Control Plane vs. Management Plane vs. Plattform. Prüfen, ob CLI/Telemetry gleichzeitig degraded ist und welche Funktionen zuerst leiden (BGP/OSPF/ARP/SSH).
• Minute 3–6: CPU Breakdown sammeln: pro Prozess, user/system/interrupt. Parallel: wichtigste Logs (neighbor down/up, link flaps, CoPP drops, ARP/ND warnings).
• Minute 6–9: Punt/Exception/CoPP prüfen: Welche Klassen droppen? Steigen punt counters? Das ist der stärkste Overload-Nachweis.
• Minute 9–12: Verursacher eingrenzen: Flow Telemetry (Top PPS, viele kurze Flows, traffic to router IP), oder quick capture an einem Hotspot.
• Minute 12–15: Mitigation wählen: CoPP/ACL/rate-limit oder isolate source; management load reduzieren. Danach verifizieren: CPU sinkt, Drops sinken, Protokolle stabilisieren. Ergebnis in 3–5 Sätzen dokumentieren (Ursache, Beweis, Maßnahme, Effekt).

Weiterführende Quellen

• RFC 2863 für Interface-Counter (IF-MIB) als Basis für Abgrenzung von Congestion vs. Fehlerbildern
• RFC 7011 (IPFIX Protocol) als Standardreferenz für Flow Telemetry zur Verursacher-Suche
• RFC 2328 (OSPFv2) für Verständnis von Hellos/Dead-Timern und warum CPU/Delay Adjazenzen destabilisiert
• RFC 4271 (BGP-4) für Session-Mechanik und Keepalive/hold-time Zusammenhänge bei Control Plane Stress
• tcpdump Manpage und Wireshark Dokumentation für gezielte Captures zur Beweisführung bei punt/exception 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.