Hohe CPU-Auslastung auf einem Switch ist ein ernstes Warnsignal: Management wird träge, SSH hängt, SNMP liefert keine Werte mehr, STP konvergiert langsamer und im Worst Case verliert der Switch Control-Plane-Funktionen. Wichtig ist die richtige Einordnung: Der meiste Transit-Traffic läuft im ASIC (Data Plane) und belastet die CPU kaum. High CPU entsteht daher typischerweise durch Control-Plane-Traffic (ARP, STP, Routing/Neighbor), Exception-Traffic (Pakete, die „zur CPU“ müssen), Flooding/Loops oder durch Management-Stress (zu aggressives SNMP/Logging). Dieser Guide zeigt, wie du High CPU strukturiert analysierst, die Ursache belegst und mit praxistauglichen Gegenmaßnahmen stabilisierst.
Erster Check: Ist es ein Spike oder dauerhaft hoch?
Unterscheide kurzzeitige Peaks (z. B. nach Topology Change) von dauerhaft hoher CPU. Dauerlast ist fast immer ein Design-/Fehlerzustand.
CPU-Status und Verlauf
show processes cpu sorted
show processes cpu history
show platform cpu packet statistics
Wichtige Fragen
- Seit wann ist die CPU hoch (Minuten vs. Stunden/Tage)?
- Ist Management betroffen (SSH/SNMP träge)?
- Gibt es parallel Link-Flaps oder STP-Events?
Typische Ursachen-Kategorien: Wo du suchen musst
High CPU ist fast immer einer dieser Bereiche zuzuordnen. Wenn du die Kategorie erkennst, halbiert sich der Troubleshooting-Aufwand.
- Layer-2 Instabilität: Loops, MAC-Flapping, viele TCNs
- ARP/Neighbor-Stress: ARP Storm, DAI/DHCP Snooping Drops
- Exception-Traffic: Pakete werden zur CPU „gepunted“
- Management-Stress: SNMP Polling, Syslog Flood, SSH Brute Force
- Routing/Control: OSPF/EIGRP/BGP (bei L3-Switch), Nachbarschaft flappt
Schritt 1: Top-CPU-Prozess finden (schnellster Hinweis)
show processes cpu sorted zeigt dir, welcher Prozess CPU frisst. Das ist der wichtigste Einstieg, weil du die Ursache oft direkt zuordnen kannst (z. B. STP, ARP, SNMP, Logging).
show processes cpu sorted
Praxis-Interpretation (typische Treffer)
- STP-/L2-Prozesse hoch: Loop, TCNs, Topologie instabil
- ARP/CEF/Adjacency hoch: ARP-Last, Spoofing, L3-Exception
- SNMP hoch: Polling zu aggressiv oder zu viele OIDs
- Syslog/Logging hoch: Log-Flood (Storms, Security Drops, Debugs)
Schritt 2: STP/Loop-Indikatoren prüfen (häufigste High-CPU Ursache im Access)
Loops und flappende Uplinks verursachen Broadcast/Unknown-Unicast Flooding und ständig neue STP-Berechnungen. Das kann CPU stark belasten und gleichzeitig das Netz „gefühlt lahm“ machen.
STP und TCNs prüfen
show spanning-tree summary
show spanning-tree root
show spanning-tree vlan 10 detail
show spanning-tree inconsistentports
MAC-Flapping und Storm-Indikatoren
show logging | include MACFLAP|TOPOLOGY|SPANNING|STORM
show storm-control
Sofortmaßnahmen bei Loop-Verdacht
- Verdächtigen Edge-Port isolieren (shutdown)
- BPDU Guard/PortFast prüfen (Edge-Härtung)
- Uplinks/Port-Channels auf Konsistenz prüfen
Schritt 3: ARP/DHCP/DAI-Indikatoren prüfen (Spoofing und Floods)
ARP Storms oder Spoofing führen zu hoher Control-Plane-Last. In gehärteten Netzen sieht man oft viele DAI- oder DHCP Snooping Drops, die zusätzlich Logging erzeugen.
DHCP Snooping / DAI prüfen
show ip dhcp snooping
show ip dhcp snooping binding
show ip arp inspection
show ip arp inspection vlan 10
show logging | include DHCP|SNOOP|ARP|INSPECTION|DAI|DROP
Sofortmaßnahmen
- Rogue DHCP Quelle identifizieren (Drops/Port)
- DAI Rate-Limits prüfen/anpassen
- ARP Flooding-Port isolieren
Schritt 4: Management Plane Stress prüfen (SNMP, SSH, Syslog)
Management-Traffic kann CPU belasten, ohne dass das Netz „kaputt“ ist. Typisch sind zu aggressive SNMP Poller, zu viele Syslog-Meldungen pro Sekunde oder SSH-Brute-Force.
SNMP/Logging/SSH Indikatoren
show running-config | include snmp-server
show snmp group
show snmp user
show logging
show users
show ssh
Brute-Force und Login-Events erkennen
show logging | include SSH|LOGIN|AUTH|FAIL|SEC_LOGIN
Gegenmaßnahmen (Management)
- VTY-ACL: SSH nur aus Admin-Netzen
- SNMP Polling reduzieren (Intervalle/OIDs), SNMPv3 nutzen
- Syslog-Rate senken (Trap-Level), Log-Flood-Ursache beheben
- Login-Blockierung aktivieren
Schritt 5: Exception-Traffic und „CPU Punt“ erkennen
Bestimmte Pakete werden zur CPU geschickt (z. B. unbekannte Features, ACL-Exceptions, Control-Plane-Protokolle). Wenn das plötzlich viel wird, steigt CPU. Plattformabhängig liefern „platform“ Befehle Hinweise.
Plattform-Statistiken (falls verfügbar)
show platform cpu packet statistics
show platform software fed active cpu-interface
Indikatoren
- Viele „punted“/„exception“ Pakete
- CPU hoch ohne offensichtliche STP/ARP/Management Events
- Parallel hohe Broadcast/Unknown-Unicast Raten auf Uplinks
Sofortmaßnahmen: Stabilität herstellen, bevor du „perfekt“ analysierst
Wenn der Switch kaum noch bedienbar ist, priorisiere Stabilisierung: Management sichern, offensichtliche Flood-Quellen isolieren und die Log-Flut reduzieren. Danach folgt die Detailanalyse.
- Verdächtige Edge-Ports mit vielen MACs/Storms shutdown
- Uplinks/Port-Channels prüfen (Flaps, CRC, Bundle)
- Syslog-Noise reduzieren, falls Management blockiert
- Out-of-band Zugriff nutzen (Console), wenn SSH hängt
Verdächtige Ports schnell finden (Heuristik)
show interfaces status
show mac address-table count
show mac address-table dynamic | include Gi1/0/
show interfaces counters errors
Beweisführung: Wie du die Ursache sauber dokumentierst
Für Tickets/Change brauchst du einen Nachweis: CPU-Prozess + korrelierende Logs/Counters. Dokumentiere Zeit, CPU-Top-Prozesse, betroffene Ports und Events.
Minimaler Evidence-Block
show clock
show processes cpu sorted
show processes cpu history
show spanning-tree summary
show ip dhcp snooping binding
show ip arp inspection vlan 10
show interfaces counters errors
show logging | include SPANNING|TOPOLOGY|MACFLAP|DHCP|SNOOP|ARP|INSPECTION|SSH|SNMP
Langfristige Gegenmaßnahmen: High CPU dauerhaft vermeiden
Die nachhaltigsten Maßnahmen sind Standards: Edge-Härtung gegen Loops/Storms, Spoofing-Schutz im Access, sauberes Trunking und eine gehärtete Management Plane. Damit bleibt die CPU auch in Fehlerfällen beherrschbar.
- PortFast + BPDU Guard default, Root/Loop Guard konsistent
- Storm Control auf Edge-Ports (Broadcast/Multicast/Unknown-Unicast)
- DHCP Snooping + DAI + IP Source Guard in Client-VLANs
- LACP-Port-Channels für Uplinks, Trunks whitelisten, Native VLAN ungenutzt
- Management: SSH-only, VTY-ACL, AAA, SNMPv3, Logging sauber dimensionieren
copy running-config startup-config
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze
-
Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
-
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
-
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
-
Optional Security: Basic ACLs und SSH-Hardening
-
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)
Sie erhalten
-
✅ Packet Tracer .pkt Datei
-
✅ Saubere Konfigurations-Notizen pro Gerät
-
✅ Verifikations-Checkliste + erwartete Outputs
-
✅ Kurze Dokumentation (wie die Topologie funktioniert)
Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.
