Memory Leaks & CPU Spikes: IOS XE Debug-Strategien ohne Netz-Ausfall

Memory Leaks und CPU Spikes auf IOS XE sind besonders kritisch, weil sie oft schleichend beginnen und dann plötzlich Routing, Management oder sogar Forwarding beeinträchtigen. Das Hauptziel im Betrieb ist daher: Diagnose sammeln, ohne den Router durch aggressive Debugs zu destabilisieren. In der Praxis heißt das: erst „read-only“ messen (CPU/Memory/Logs/Platform), dann gezielt eingrenzen (welcher Prozess, welche Traffic-Klasse, welche Trigger), und erst ganz am Ende kurze, stark gefilterte Debug-Fenster nutzen – idealerweise außerhalb der Peak-Zeit und mit klarer Abbruchregel.

Grundprinzip: Diagnose ohne Selbst-DDOS

Viele Debugs sind CPU-intensiv und können die Lage verschlimmern. Du arbeitest daher nach dem Prinzip „least intrusive first“: Counters und Snapshots vor Live-Debug.

• Phase 1: Snapshot (CPU/Memory/Platform/Logs) – risikoarm
• Phase 2: Korrelation (Zeit, Interface, Policy, Punt/CoPP) – zielgerichtet
• Phase 3: Minimal-Debug (kurz, gefiltert, mit Kill-Switch) – nur wenn nötig

Phase 1: CPU-Spike sauber messen (wer frisst CPU?)

CPU-Spikes sind oft „ein Prozess“, aber die Ursache kann Traffic (Punt), Routing-Flaps oder Management-Scans sein. Du brauchst daher Prozessliste plus Kontext.

CPU Snapshot (sorted)

show processes cpu sorted
show processes cpu history
show platform software status control-processor brief

Interpretation (praxisnah)

• Viele Prozesse moderat hoch: oft Systemdruck (Punt/Interrupt/IO)
• Ein Prozess dominiert: oft Feature-spezifisch (Routing, Crypto, Mgmt)
• CPU-History zeigt Muster: periodisch (Timer) vs. dauerhaft (Leak/Storm)

Phase 1: Memory Leak vs. „nur wenig frei“ unterscheiden

Memory „knapp“ ist nicht automatisch ein Leak. Ein Leak zeigt sich typischerweise als stetig wachsender Verbrauch ohne Rückgang, oft in einem Pool oder Prozess. Du brauchst mehrere Messpunkte über Zeit.

Memory Snapshot

show processes memory sorted
show memory statistics
show memory summary

Leak-Indiz als Denkmodell

$\text{Memory(t)}\nearrow \text{kontinuierlich} und \text{keine Erholung} \to \text{Leak-Verdacht}$

Phase 1: Platform- und Crash-Indizien prüfen

Bevor du „Debug“ machst, prüfe, ob es bereits Crash-/Restart-Indizien gibt. Das spart Zeit und liefert TAC-taugliche Daten.

show version
show platform
show logging | include CRASH|TRACEBACK|MEMORY|CPU|PUNT|HW|PLATFORM

Phase 2: Häufige Ursachen für CPU-Spikes (ohne Debug erkennbar)

Viele CPU-Spikes haben klare Muster. Wenn du sie erkennst, brauchst du oft keinen Debug, sondern einen Policy-/Design-Fix.

Punt/Control-Plane-Flood (Scans, ICMP, Mgmt)

• Symptom: hohe CPU, CoPP-Drops steigen, viele kleine Pakete
• Fix: Management absichern, CoPP tunen, ACLs an Edge

show policy-map control-plane
show processes cpu sorted
show logging | include COPP|PUNT|CPU

Routing-Flaps (OSPF/BGP Nachbarn instabil)

• Symptom: CPU-Spikes korrelieren mit Neighbor up/down
• Fix: Link-Qualität, Timer, MTU, Auth, BFD (wenn sinnvoll)

show ip ospf neighbor
show ip bgp summary
show logging | include OSPF|BGP|ADJCHG|NEIGHBOR

Crypto/ VPN (Rekey-Storm, DPD, Phase 2 churn)

• Symptom: Crypto-Prozesse hoch, viele SA-Neuverhandlungen
• Fix: MTU/MSS, NAT-T/ACL, Rekey-Parameter konsistent

show crypto isakmp sa
show crypto ipsec sa
show logging | include ISAKMP|IKE|IPSEC

Phase 2: Memory Leak eingrenzen (welcher Prozess wächst?)

Wenn ein Prozess in show processes memory sorted kontinuierlich nach oben wandert, hast du einen starken Kandidaten. Sammle mehrere Snapshots im Abstand, statt sofort zu debuggen.

Repeatable Snapshots (Beispiel: alle 10–15 Minuten)

show processes memory sorted
show memory statistics
show logging | last 50

„Safe Debugging“: Regeln, die Netz-Ausfälle verhindern

Wenn du debuggen musst, reduziere Risiko: kurze Dauer, starke Filter, Monitoring aktiv, und sofortiges Abschalten. Debug ohne Kill-Switch ist im Betrieb gefährlich.

• Nur wenn CPU nicht bereits kritisch hoch ist
• Nur mit terminal monitor gezielt in einer Session
• Debugs zeitlich begrenzen (z. B. 30–60 Sekunden)
• Immer undebug all als Notbremse

Kill-Switch

undebug all

Phase 3: Debug-Strategien für CPU-Spikes (kurz und gefiltert)

Ziel ist, den Trigger zu sehen: welche Events starten den Spike? Wähle Debugs nur für den betroffenen Stack (Routing/Crypto/AAA) und nutze Filter, wenn verfügbar.

Routing-Debug (nur bei Neighbor-Problemen)

terminal monitor
debug ip ospf adj
debug ip bgp updates
undebug all

Crypto-Debug (nur bei IKE/IPsec Problemen)

terminal monitor
debug crypto isakmp
debug crypto ipsec
undebug all

AAA/SSH Debug (nur bei Login/AAA-Spikes)

terminal monitor
debug aaa authentication
debug ip ssh
undebug all

Alternative zu Debug: „Beweise sammeln“ mit Show-Tech

Wenn Debug zu riskant ist, sammle TAC-taugliche Beweise. show tech-support kann groß sein, ist aber in vielen Fällen sicherer als dauerhafte Debugs.

show tech-support
show logging | last 500
copy running-config scp:

Mitigation während der Analyse: Stabilität gewinnen

Wenn CPU/Memory kritisch werden, kann eine temporäre Mitigation nötig sein, um Zeit zu kaufen. Ziel: Last reduzieren, ohne Kernservices zu zerstören.

• Management-Zugriffe einschränken (VTY ACL, SNMP Scope)
• Control-Plane schützen (CoPP aktivieren/verschärfen)
• Sampling/NetFlow reduzieren, wenn es messbar beiträgt
• VPN-Rekey-Stürme durch MTU/MSS und stabile Peers beruhigen

CoPP Status prüfen

show policy-map control-plane

Entscheidungspunkt: Wann ist ein Reload/Upgrade sinnvoll?

Ein Memory Leak endet oft nur mit Prozess-Neustart oder Reload. Betrieblich ist das kein „Scheitern“, sondern eine kontrollierte Stabilisierung, wenn du vorher genug Evidence gesammelt hast und ein Maintenance Window verfügbar ist.

• Leak bestätigt (wächst reproduzierbar) → TAC/Upgrade-Plan
• CPU-Spikes durch Bug/Crash-Indizien → Upgrade/SMU prüfen
• Vor Reload: Config sichern, Evidence sichern, Rollback-Plan

Quick-Runbook: CPU/Memory Incident ohne Ausfall (Copy & Paste)

Dieses Set ist als „low risk first“ gedacht: messen, korrelieren, erst dann ggf. minimal debuggen.

show clock
show version
show platform software status control-processor brief
show processes cpu sorted
show processes cpu history
show processes memory sorted
show memory statistics
show policy-map control-plane
show ip interface brief
show ip ospf neighbor
show ip bgp summary
show crypto isakmp sa
show crypto ipsec sa
show logging | last 200
show tech-support

Konfiguration speichern

Router# 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.