Problem Management: Root-Cause-Analyse von Cisco-Router-Incidents und Preventive Actions

Problem Management für Cisco-Router-Incidents bedeutet: Sie beheben nicht nur Symptome, sondern identifizieren wiederkehrende Ursachen, definieren Preventive Actions und senken nachhaltig MTTR sowie Incident-Rate. In vielen Netzwerken werden Störungen „gelöscht“, sobald der Service wieder läuft – damit bleiben Root Causes (Routing-Instabilität, Provider-Path-Down, MTU/MSS, CPU-Spikes, Policy-Drift) bestehen und kehren zurück. Ein production-grade Vorgehen verbindet Incident Evidence (CLI/Logs), strukturierte Root-Cause-Analyse (RCA), messbare Maßnahmen (CAPA) und Governance (Templates, Change-Standards, Monitoring). Dieser Leitfaden zeigt ein praxistaugliches Framework für RCA und Preventive Actions bei Cisco-Router-Incidents.

Incident vs. Problem: Warum Problem Management ein eigener Prozess ist

Ein Incident wird gelöst, wenn der Service wiederhergestellt ist. Ein Problem ist gelöst, wenn die Ursache behoben oder kontrolliert ist. Problem Management arbeitet daher mit Zeit, Daten und Priorisierung.

• Incident: Restore ASAP (Workaround/Rollback)
• Problem: Root Cause identifizieren, Wiederholung verhindern
• Output: RCA-Report + Preventive Actions + Tracking bis Closure

Inputs für RCA: Ohne Evidence keine belastbare Ursache

Eine RCA ist nur so gut wie die Daten. Definieren Sie ein Evidence Pack als Pflicht für P1/P2-Incidents, sonst bleibt die Analyse spekulativ.

• Zeitbasis: NTP synchronized, show clock im Ticket
• Topologie: betroffene Links, Provider, VPNs, Routing-Peers
• Symptom: was genau war kaputt (Impact) und wie wurde es bemerkt?
• Timeline: Start, Detection, Mitigation, Restore, Stabilisierung

CLI: Incident Evidence Pack (Minimum)

show clock
show ntp status
show ip interface brief
show interfaces counters errors
show interfaces | include output drops|queue
show ip route 0.0.0.0
show ip route summary
show ip ospf neighbor
show bgp summary
show crypto ipsec sa
show ip sla statistics
show track
show logging | last 200
show processes cpu sorted

RCA-Workflow: Von Symptom zu Root Cause in 6 Schritten

Ein klarer Workflow verhindert, dass RCA zum „Meinungsmeeting“ wird. Arbeiten Sie von Fakten (Timeline/Evidence) zu Hypothesen und validieren Sie jede Hypothese mit Daten.

• Schritt 1: Impact definieren (Services, Nutzer, Standorte, Dauer)
• Schritt 2: Timeline bauen (Detection → Mitigation → Restore)
• Schritt 3: Technische Hypothesen (WAN, Routing, VPN, Policy, CPU)
• Schritt 4: Hypothesen verifizieren (Logs/Counter/Events)
• Schritt 5: Root Cause + Contributing Factors dokumentieren
• Schritt 6: Preventive Actions als CAPA ableiten und verfolgen

RCA-Methoden: 5-Why und Fault Tree (praxisnah)

Für Router-Incidents funktionieren zwei Methoden besonders gut: 5-Why (schnell) und Fault Tree (systematisch). Entscheidend ist, dass Sie zwischen Ursache und Auslöser unterscheiden.

5-Why (Beispielstruktur)

• Warum war Service down? → Default Route zeigte auf falschen Pfad
• Warum falscher Pfad? → Tracking erkannte Path-down nicht
• Warum nicht? → IP SLA Ziel war nur Provider-GW, nicht Internet/HQ
• Warum so konfiguriert? → Template fehlte, manuelle Ausnahme
• Warum Template fehlte? → keine Governance/Review für Dual-ISP Modul

Fault Tree (Beispielknoten)

• Service Down
• → WAN Path Down (ISP/Upstream)
• → Routing Convergence Failure (BGP/OSPF/Static)
• → VPN Traffic Failure (No-NAT/Selectors/MTU)
• → Device Resource Exhaustion (CPU/Memory/Queue Drops)

Typische Root Causes bei Cisco-Routern und wie Sie sie verifizieren

Viele RCAs wiederholen sich. Nutzen Sie Muster, aber verifizieren Sie immer mit Evidence. Das reduziert Zeit und erhöht Qualität.

Root Cause Muster 1: Path-down ohne Link-down (Failover versagt)

• Symptom: Link up, aber Internet/HQ nicht erreichbar, sporadische Ausfälle
• Evidence: Track bleibt up, obwohl Probes fehlschlagen oder Ziel unpassend
• Preventive Action: IP SLA Targets verbessern, Track-Delays, UAT Path-down Tests

CLI: Tracking Evidence

show ip sla statistics
show track
show ip route 0.0.0.0
show logging | include TRACK|IP_SLA

Root Cause Muster 2: Routing Flaps/Loops (Policy/Redistribution)

• Symptom: Instabilität, CPU-Spikes, wechselnde Pfade, Blackholes
• Evidence: Neighbor flaps, unerwartete Routen, wiederkehrende Logevents
• Preventive Action: Prefix-Filter, max-prefix, Peer-Review, Redistribution-Regeln

CLI: Routing Evidence

show ip route summary
show ip ospf neighbor
show bgp summary
show logging | include OSPF|BGP

Root Cause Muster 3: VPN „SA up“, aber kein Traffic (No-NAT/Routes)

• Symptom: Tunnel steht, Applikationen down, Counter bleiben 0
• Evidence: IPsec SAs vorhanden, aber keine Pakete/Bytes steigen
• Preventive Action: No-NAT Standard, UAT Traffic-Path Tests, Template-Selectors

CLI: VPN Evidence

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show ip nat statistics

Root Cause Muster 4: MTU/MSS Blackholes (Performance/Abbrüche)

• Symptom: bestimmte Seiten/Downloads brechen, VPN langsamer, nur große Pakete betroffen
• Evidence: DF-Pings schlagen bei großer Größe fehl, Queue Drops/Fragmentation
• Preventive Action: MSS-Clamp, PMTUD ICMP gezielt erlauben, Post-Change Perf Checks

CLI: MTU/MSS Evidence

ping 1.1.1.1 size 1472 df-bit repeat 5
ping 1.1.1.1 size 1400 df-bit repeat 5
show interfaces | include MTU
show interfaces | include output drops|queue

Root Cause Muster 5: CPU/Memory Exhaustion (Control Plane/Traffic)

• Symptom: langsames Management, Routing-Protokolle instabil, sporadische Drops
• Evidence: CPU dauerhaft hoch, Control Plane Drops, Prozess-Spitzen
• Preventive Action: CoPP, Rate-Limits, Telemetry/NetFlow prüfen, Kapazitätsplanung

CLI: Resource Evidence

show processes cpu sorted
show processes memory sorted
show policy-map control-plane

Contributing Factors: Was die Ursache „groß“ gemacht hat

In Enterprise-RCAs ist Root Cause oft nur ein Teil. Contributing Factors erklären, warum der Incident so lange dauerte oder so viele Systeme traf.

• Fehlendes Monitoring/Alerting (Detection zu spät)
• Keine Baselines/Runbooks (Diagnose zu langsam)
• Unklare Demarkation (Router vs. Firewall vs. ISP)
• Fehlender OOB-Zugriff (Recovery verzögert)
• Drift/Ad-hoc Changes ohne Change-ID (Nachvollziehbarkeit fehlt)

Preventive Actions: CAPA-Plan, der wirklich wirkt

Preventive Actions müssen konkret, messbar und terminiert sein. Ein guter CAPA-Plan enthält technische Maßnahmen, Prozessmaßnahmen und einen Owner pro Action.

• Corrective Action: direkte technische Behebung (Fix, Patch, Policy)
• Preventive Action: Wiederholung verhindern (Templates, Monitoring, SOP)
• Owner/Deadline: verantwortliche Rolle und Datum
• Success Metric: KPI, die Verbesserung zeigt (MTTR, Incident Rate, Flaps)

Beispiele für Preventive Actions (Cisco-Router)

• Dual-ISP: IP SLA Targets standardisieren, Path-down UAT verpflichtend
• Routing: Peer-Review für BGP/Redistribution, max-prefix als Standard
• VPN: No-NAT Check in Pre-Change, Traffic Counter in UAT als Gate
• MTU: MSS-Clamp Standard für VPN/PPPoE, DF-Ping Test in Post-Checks
• Operations: Evidence Pack Pflicht, Runbook aktualisieren, KT-Session

RCA-Report: Struktur für ein auditierbares Problem-Record

Ein guter RCA-Report ist kurz, aber vollständig. Er muss Impact, Ursache, Evidence und Maßnahmen enthalten. Das ist die Grundlage für Problem-Closure.

• Summary: was passiert ist (1–3 Sätze)
• Impact: Services/Standorte/Dauer/Business-Impact
• Timeline: Detection, Mitigation, Restore, Stabilisierung
• Root Cause + Contributing Factors: mit Evidence-Referenzen
• Actions: CAPA-Liste mit Owner, Deadline, Success Metric

Problem-Closure: Wann ein Problem wirklich geschlossen ist

Ein Problem ist nicht geschlossen, wenn der Fix „geplant“ ist, sondern wenn Maßnahmen umgesetzt und wirksam sind. Definieren Sie Closure-Kriterien.

• Fix implementiert und über Change-Prozess ausgerollt
• UAT/Verification bestanden, Evidence abgelegt
• Monitoring aktualisiert (neue Alarme/KPIs)
• Trend verbessert: weniger Wiederholungen oder niedrigere MTTR

CLI: Post-Fix Verification Pack (Copy/Paste)

show clock
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip sla statistics
show track
show crypto ipsec sa
show policy-map interface
show ntp status
show logging | last 100
show processes cpu sorted

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.