High CPU auf Cisco: Ursachen, Show Commands und Mitigation

High CPU auf Cisco ist eines der häufigsten Warnsignale im Netzwerkbetrieb, weil es nicht nur die Performance eines einzelnen Geräts betrifft, sondern schnell zu Folgeschäden führen kann: Management-Zugriff wird träge, Routing-Protokolle flappen, STP reagiert verzögert, BGP-Updates stauen sich, Telemetrie bricht weg und im Extremfall kommt es zu Watchdog-Resets. Gleichzeitig ist „CPU hoch“ kein eigenständiger Fehler, sondern ein Symptom – und ohne strukturierten Diagnose-Workflow wird viel Zeit mit Aktionismus verbrannt (z. B. blindes Neustarten von Prozessen oder unnötige Reboots). Professionelles Troubleshooting auf Cisco IOS/IOS XE und NX-OS beginnt mit zwei Fragen: Handelt es sich um echte Last durch Daten-/Control-Plane-Ereignisse (z. B. Routing-Churn, Broadcast-Sturm, DoS) oder um Management-Plane-Last (SNMP-Polling, Logging, NetFlow-Exports, API-Abfragen, Debugs)? Und zweitens: Ist die CPU-Last „prozessgetrieben“ (ein Prozess frisst CPU) oder „interrupt-/punt-getrieben“ (Pakete werden zur CPU gepuntet, z. B. durch fehlendes CEF, MTU/Fragmente, ACL-Logging, ARP-Stürme)? Wer diese Unterscheidung früh trifft, verkürzt die Mean Time to Recovery deutlich und reduziert das Risiko, durch falsche Maßnahmen weitere Instabilität zu erzeugen.

Erstes Ziel: Impact und Zeitverlauf einordnen

High CPU ist nicht automatisch kritisch. Entscheidend ist, ob die Last konstant hoch ist oder nur in kurzen Spitzen auftritt, und ob betriebliche Symptome sichtbar sind. Beginnen Sie deshalb mit einer schnellen Einordnung:

• Konstant vs. Spike: Eine CPU-Spitze nach einer Routing-Änderung ist normal, eine dauerhaft hohe CPU deutet auf anhaltende Ursache (Storm, DoS, Polling, Loop).
• Auswirkung: Ist SSH/CLI langsam? Gibt es Routing-Neighborship-Flaps? Kommen Syslog/Telemetry verzögert?
• Scope: Betrifft es nur ein Gerät oder mehrere in derselben Site/Role? Mehrere Geräte sprechen oft für L2-Storm oder Control-Plane-Event.

Diese Einordnung bestimmt, ob Sie sofort mitigieren müssen (z. B. Traffic begrenzen) oder zuerst sauber messen können.

CPU-Lasttypen: Prozess-CPU, Interrupt-CPU und „Punt“-Signaturen

Auf Cisco-Plattformen ist es entscheidend, zwischen Prozesslast und Interrupt-/Puntlast zu unterscheiden. Eine hohe Interrupt-CPU bedeutet häufig, dass ungewöhnlich viel Traffic zur CPU gelangt – etwa durch Prozess-Switching, ARP/ND-Stürme, fragmentierte Pakete oder Kontrolltraffic.

• Prozess-CPU: Ein oder wenige Prozesse dominieren (z. B. Routing-Protokoll, SNMP, Crypto, Logging).
• Interrupt-CPU: Hohe Interrupt-Anteile deuten auf paketgetriebene Last hin (Punts zur CPU, Treiber/Hardware-Events).
• Punt/Process Switching: Wenn Traffic nicht hardware-/CEF-geswitcht werden kann, wird er zur CPU gepuntet.

Das ist die wichtigste Diagnosegabel: Für Prozess-CPU suchen Sie den Prozess und seine Ursache. Für Interrupt/Punt suchen Sie den Traffic-Typ und warum er nicht in Hardware behandelt wird.

Show Commands, die immer zuerst kommen sollten

Ein effizienter Workflow nutzt wenige Kommandos mit hoher Aussagekraft. Die konkreten Kommandos variieren leicht nach IOS/IOS XE/NX-OS, das Prinzip bleibt gleich.

• show processes cpu sorted (IOS/IOS XE) zur Identifikation der Top-CPU-Prozesse
• show processes cpu history für den Zeitverlauf (Spikes vs. konstant)
• show platform hardware qfp active datapath utilization (bei bestimmten IOS XE/ASR/ISR Plattformen) für dataplane-/punt-Indikatoren
• show interface und show interface counters für Errors, Drops, Broadcast/Multicast-Anteile
• show logging bzw. Syslog-Statistiken, um Log-Flooding zu erkennen
• show ip cef bzw. CEF/Forwarding-Status, um Process Switching als Ursache zu prüfen
• show processes memory (oder NX-OS-Äquivalent), um Memory-Pressure als Verstärker zu erkennen

Praxis-Tipp: Beginnen Sie immer mit „sorted“ (Top Consumers) und „history“ (Trend). Ohne Trenddaten riskieren Sie, einen bereits abklingenden Spike zu „beheben“ und dabei neue Fehler einzuführen.

Die häufigsten Ursachen für High CPU auf Cisco

In Enterprise-Netzen wiederholen sich die Root Causes. Wenn Sie diese Ursachencluster kennen, sparen Sie viel Zeit:

• Control-Plane-Events: Routing-Flaps (OSPF/BGP/IS-IS), STP Topology Change Storms, ARP/ND-Churn
• L2-Stürme/Loops: Broadcast/Unknown-Unicast-Stürme durch Fehlverkabelung oder Rogue Switches
• Management-Plane-Last: SNMP Polling zu aggressiv, API-Abfragen, NetFlow/Telemetry, zu viele Syslogs
• Security/Attack: DoS auf Control Plane, Scan-Wellen, ICMP/ARP-Floods, BGP- oder OSPF-Scans
• Feature-Punts: ACL Logging, Policy Based Routing, Fragmentierung, IP Options, uRPF-Fehlkonfiguration
• Crypto: IPsec/TLS/SSH mit hoher Rate, ineffiziente Cipher oder fehlende Hardwarebeschleunigung
• Software/Leak: Bugs, Memory-Leaks, Prozess hängt oder dreht (besonders nach Upgrades/Changes)

Workflow 1: Prozess-CPU sauber analysieren

Wenn ein Prozess in show processes cpu sorted klar dominiert, haben Sie einen guten Einstieg. Ziel ist, die Aktivität des Prozesses in einen Kontext zu setzen: Welche Funktion erfüllt er, und warum ist sie gerade so aktiv?

Routing-Prozesse (OSPF/BGP/EIGRP/IS-IS)

• Typische Ursache: Instabile Nachbarschaften, Flaps, aggressive Timer, fehlerhafte Redistribution, ständiger LSA/Update-Churn
• Quick Checks: Neighbor-States stabil? Anzahl SPF/Updates ungewöhnlich? Gibt es Interfaces mit Flaps?
• Mitigation: Ursache stabilisieren (Link/Neighbor), Timer nicht blind verschärfen, Redistribution sauber filtern

SNMP / Telemetry / Management-Agenten

• Typische Ursache: Zu hohe Poll-Frequenz, zu große Tabellen (z. B. Interface Counters, CAM/ARP), zu viele Collector
• Quick Checks: Korrelation mit Monitoring-Intervallen, Peaks jede Minute/5 Minuten, viele SNMP-Requests
• Mitigation: Poll-Interval erhöhen, nur notwendige OIDs abfragen, SNMPv3 effizient konfigurieren, Collector-Anzahl begrenzen

Logging/TTY/Console-Prozesse

• Typische Ursache: Syslog-Flooding (z. B. Link flaps), Debugs, ACL logging, zu hohe console logging
• Quick Checks: Viele identische Logzeilen, hoher Output, Terminal hängt
• Mitigation: Debugs sofort beenden, console logging reduzieren, ACL logging nur gezielt einsetzen

Crypto/SSH

• Typische Ursache: Viele SSH-Sessions, starke Cipher ohne Offload, IPsec-Tunnel unter hoher Last
• Quick Checks: Peaks korrelieren mit VPN-Traffic oder Admin-Aktivität
• Mitigation: Cipher-Strategie prüfen, Offload-Fähigkeit nutzen, Session-Anzahl begrenzen

Workflow 2: Interrupt-/Punt-CPU und paketgetriebene Last finden

Wenn die CPU hoch ist, aber kein einzelner Prozess dominiert, oder wenn Interrupt-Anteile auffällig sind, ist paketgetriebene Last wahrscheinlich. Dann suchen Sie nicht „den Prozess“, sondern den Traffic-Typ, der zur CPU gelangt.

• Broadcast/Multicast-Sturm: Prüfen Sie Interface-Counter (Broadcast/Multicast), STP Topology Changes, MAC-Flapping.
• ARP/ND Storm: Viele ARP/ND Einträge wechseln, ARP-Requests steigen; häufig durch IP-Konflikte oder Loop.
• Process Switching: CEF deaktiviert oder nicht verfügbar; bestimmte Features zwingen Punts.
• Fragmentierung/IP Options: Pakete mit IP Options oder Fragmente können CPU belasten, besonders auf Edge-Geräten.

In dieser Kategorie ist Mitigation häufig „Traffic begrenzen“ und „Ursache isolieren“: betroffene VLANs/Uplinks, Storm Control, Guard Features, CoPP.

STP, Loops und Broadcast-Stürme als CPU-Treiber

Ein Layer-2-Loop ist eine der häufigsten Ursachen für High CPU in Campus-Netzen: BUM-Traffic steigt, MAC-Tabellen flappen, STP produziert Topology Changes, und die CPU verbringt Zeit mit Management- und Control-Plane-Aufgaben.

• Indikatoren: Hohe Broadcast-Rate, MAC-Flapping-Meldungen, viele TCs, Interface Drops, CPU-Spikes auf mehreren Switches
• Mitigation: Segment isolieren (Uplink), Storm Control prüfen/aktivieren, BPDU Guard/Root Guard als Baseline, Rogue Switch entfernen

Für STP-spezifische Diagnosemuster ist die Cisco-Referenz zu Spanning Tree Protocol Troubleshooting hilfreich.

Routing-Churn: Wenn OSPF/BGP die CPU dauerhaft hoch hält

Routing-Protokolle sind CPU-sensitiv, wenn die Topologie instabil ist. Häufige Ursachen sind Link-Flaps, aggressive BFD-Timer, instabile Peers oder fehlerhafte Redistribution, die ständig neue Updates erzeugt.

• OSPF: Viele SPF-Läufe, Neighbor-Flaps, LSA-Churn; häufig auch MTU-/Auth-/Network-Type-Probleme als Auslöser
• BGP: Session-Flaps, viele Updates, Route-Refresh-Stürme, Route-Map-Fehler, die wiederholt Policies anwenden

Als Referenz eignen sich RFC 2328 (OSPFv2) und RFC 4271 (BGP-4) für die Protokollgrundlagen; für praktische Cisco-Workflows sind Cisco OSPF Troubleshooting Guidelines und Cisco BGP Troubleshooting nützlich.

Management-Plane als Ursache: SNMP, Syslog, NetFlow und APIs

In vielen Unternehmen wird High CPU nicht durch Datenverkehr, sondern durch Management verursacht. Typisch ist eine Monitoring-Änderung (neuer Collector, kürzere Intervalle) oder eine Log-Flood-Situation.

• SNMP Polling: Zu häufiges Polling großer Tabellen (Interfaces, ARP, MAC) kann CPU drücken.
• Syslog: Link flaps oder STP-Events erzeugen tausende Logs pro Minute; console logging verstärkt den Effekt.
• NetFlow/Exporter: Exporte oder zu viele Flow-Records können Last erzeugen, je nach Plattform und Sampling.
• RESTCONF/NETCONF: Häufige API-Abfragen oder große Payloads können CPU belasten, besonders wenn viele Clients parallel arbeiten.

Mitigation ist hier oft simpel und schnell wirksam: Poll-Interval erhöhen, Collector begrenzen, Logging-Noise reduzieren, Export-Raten anpassen.

Control Plane Policing (CoPP): Schutz und Mitigation in einem

Wenn High CPU durch Control-Plane-Traffic (Scan, Flood, Fehlkonfiguration) ausgelöst wird, ist CoPP häufig das effektivste Schutzinstrument. CoPP klassifiziert Control-Plane-Pakete (z. B. Routing, ARP, ICMP, SSH) und limitiert sie, damit die CPU nicht überfahren wird.

• Nutzen: Verhindert, dass ein Flood legitime Control-Plane-Protokolle verdrängt.
• Risiko: Zu strikte CoPP-Policies können legitimen Traffic droppen (OSPF/BGP/HSRP), daher müssen sie rollenbasiert dimensioniert sein.
• Best Practice: CoPP als Golden Baseline, plus Monitoring der Drop-Counter.

Für eine konzeptionelle Einführung ist Cisco Control Plane Policing (CoPP) ein guter Startpunkt.

Schnelle Mitigation-Optionen (ohne „kaputt zu reparieren“)

Wenn die CPU hoch ist und der Betrieb leidet, brauchen Sie kurzfristige Stabilisierung. Diese Maßnahmen sind in der Praxis oft sicher, weil sie die Ursache eindämmen, ohne das Design umzubauen:

• Debugs beenden: Debug-Ausgaben sind ein häufiger CPU-Verstärker.
• Console logging reduzieren: Logs auf die Konsole sind teuer; bei Incident nur gezielt nutzen.
• Problemport isolieren: Bei Loop/Storm Verdacht den betroffenen Uplink oder VLAN-Bereich kontrolliert isolieren.
• Storm Control aktivieren/prüfen: Broadcast/Multicast begrenzen, um CPU und CAM zu stabilisieren.
• SNMP Polling drosseln: Intervall erhöhen, große Tabellen reduzieren.
• Control-Plane schützen: CoPP-Profile aktivieren/prüfen, sofern vorhanden.

Wichtig: Ein Reboot ist selten eine gute Erstmaßnahme. Er kann Symptome kurz beseitigen, aber die Ursache bleibt und kehrt oft schneller zurück.

Mitigation nach Ursache: Konkrete Fix-Patterns

• Loop/Storm: Root Cause im Access finden (Rogue Switch, Fehlpatch), Guard Features standardisieren (BPDU Guard), Storm Control Werte konsistent setzen.
• Routing-Churn: Link/Neighbor stabilisieren, aggressive Timer zurücknehmen, Redistribution filtern, Flap-Quellen beheben.
• SNMP/Telemetry: Polling-Design anpassen, Sampling nutzen, Collector konsolidieren, API-Rate Limits setzen.
• ACL Logging: Logging nur gezielt und zeitlich begrenzt, sonst CPU-Overhead vermeiden.
• MTU/Fragmentierung: Pfad-MTU konsistent machen, PMTUD-ICMP erlauben, MSS-Clamping an WAN/VPN-Edges.
• Software/Bug: Known Bugs prüfen, ggf. Maintenance Upgrade/SMU, Crashinfo sammeln und TAC einbinden.

Fehleranalyse ohne Risiko: Welche Debugs und Captures sinnvoll sind

Bei High CPU ist „mehr Debug“ oft kontraproduktiv. Wenn Sie zusätzliche Daten brauchen, nutzen Sie bevorzugt:

• Conditional Debug: Wenn Debug nötig ist, dann nur auf den betroffenen Prozess/Neighbor begrenzen und zeitlich kurz halten.
• Gezielte Captures: SPAN/ERSPAN oder Embedded Packet Capture (EPC) mit engen Filtern (z. B. ARP flood, OSPF hello, BGP TCP/179).
• Counter-basierte Beweise: Interface Counters, Drop-Counter, CoPP Drops, Queue Drops liefern oft genug Beweise ohne Debug.

Damit vermeiden Sie, dass die Diagnose selbst die CPU weiter belastet.

Monitoring und Prävention: High CPU dauerhaft verhindern

Langfristig ist High CPU ein Governance- und Standardisierungsthema. Die wirksamsten Maßnahmen sind:

• Golden Baselines: CoPP, Storm Control, Logging-Strategie, Management-ACLs, NTP/Syslog-Standards.
• Drift Detection: Abweichungen (z. B. Debug aktiv, Logging zu laut, fehlende Guards) automatisiert erkennen.
• Telemetry mit Augenmaß: Polling-/Streaming-Raten an Plattformkapazität anpassen.
• Change-Disziplin: Routing- und STP-Änderungen in Wartungsfenstern mit Preflight/Post-Checks.
• Kapazitätsplanung: CPU-Headroom definieren; dauerhaft >70–80% ist ein Risikosignal, selbst wenn „noch alles geht“.

Runbook: High CPU auf Cisco in 10 Minuten eingrenzen

• Trend prüfen: show processes cpu history (Spike oder konstant?).
• Top-Prozesse: show processes cpu sorted (Prozess-CPU vs. kein Dominator?).
• Interrupt/Punt Verdacht: Interface Broadcast/Errors/Drops prüfen, CEF/Forwarding prüfen.
• Routing/Control-Plane: Neighbor Stability (OSPF/BGP), Flaps, LSA/Update-Churn.
• L2-Storm Indikatoren: STP TCs, MAC Flapping, Storm Control.
• Management Last: SNMP/Telemetry/Logging-Frequenz, Log-Flooding.
• Mitigation: Debugs aus, console logging runter, Polling drosseln, Problemsegment isolieren, CoPP prüfen.
• Post-Checks: CPU stabilisiert? Neighbors stabil? Management erreichbar? Monitoring wieder ok?

Outbound-Referenzen

• Cisco: High CPU Utilization Troubleshooting für Cisco-spezifische Vorgehensweisen und typische Ursachencluster.
• Cisco: Spanning Tree Protocol Troubleshooting für Loop-/TCN-bezogene CPU-Ursachen im Campus.
• Cisco: OSPF Troubleshooting Guidelines für Routing-Churn-Analyse und Neighbor-Flap-Ursachen.
• Cisco: BGP Troubleshooting für Session-/Update-Probleme, die CPU-Last auslösen oder verstärken können.
• Cisco: Control Plane Policing (CoPP) für Schutzmechanismen gegen Control-Plane-Floods und als Mitigation-Tool.

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.