Cisco-Router-Troubleshooting-Framework: Systematischer Ansatz für Engineers

Ein systematisches Cisco-Router-Troubleshooting-Framework verhindert „CLI-Zapping“ und verkürzt MTTR, weil es Hypothesen datenbasiert prüft und den Scope schnell eingrenzt. Die häufigsten Fehler in Incidents sind: zu früh an der Konfiguration zu drehen, ohne Baseline; falsche Annahmen über den Traffic Path; fehlende Trennung von Device-, Link- und Service-Ebene; und fehlende Evidence für Eskalationen (ISP, Security, App-Team). Ein production-grade Ansatz folgt daher einer klaren Reihenfolge: Stabilisieren → Scope eingrenzen → Hypothesen testen → Ursache beheben → Evidence dokumentieren → Preventive Actions ableiten. Dieses Framework ist für Einsteiger verständlich, aber robust genug für Enterprise-Incidents.

Grundprinzip: Stabilisieren vor Analysieren

Bevor Sie Root Cause suchen, stellen Sie Service wieder her (Workaround/Rollback). Das reduziert Business-Impact und schafft Zeit für saubere Analyse.

• Wenn möglich: Failover aktivieren, Workaround anwenden, Rollback entscheiden
• Keine „Nebenfixes“: nur Maßnahmen mit klarer Wirkung und Dokumentation
• Kommunikation: Severity festlegen, Statusrhythmus im Incident

Framework-Übersicht: 6 Phasen für Cisco-Router-Incidents

Diese Phasen funktionieren in nahezu allen Fällen (Internet down, VPN flaps, Routing-Probleme, Performance). Jede Phase produziert Evidence.

• Phase 1: Problem definieren (Impact, Symptome, Zeitraum)
• Phase 2: Scope eingrenzen (Device vs. Link vs. Service)
• Phase 3: Hypothesen bilden (Top 3 Ursachen)
• Phase 4: Hypothesen testen (kurze Checks, klare Pass/Fail)
• Phase 5: Fix/Workaround validieren (Post-Checks, UAT)
• Phase 6: Dokumentieren und verhindern (RCA, Preventive Actions)

Phase 1: Problemdefinition (ohne diese Fragen wird alles langsamer)

Eine präzise Problemdefinition spart Zeit. Notieren Sie sie im Ticket, bevor Sie tief in die CLI gehen.

• Was ist kaputt? (Internet, VPN, Routing, einzelne App, Voice)
• Wer ist betroffen? (ein Standort, mehrere Standorte, alle)
• Seit wann? (Startzeit, Häufigkeit, Intervall)
• Was hat sich geändert? (Change Window, Providerarbeiten, neue Policies)

Phase 2: Scope eingrenzen (Device, Link, Service)

Die wichtigste Abkürzung: Prüfen Sie zuerst, ob das Gerät gesund ist, dann den Link, dann den Servicepfad. Viele „Internet down“ Fälle sind Path-down bei Link up.

• Device: Uptime, CPU/Memory, Logs, Reloads
• Link: Interface up/down, Errors/Drops, Flaps
• Service: Default Route, IP SLA/Tracking, VPN Session/Traffic

CLI: Quick Scope Check (Copy/Paste)

terminal length 0
show clock
show version
show processes cpu sorted
show processes memory sorted
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 logging | last 100

Phase 3: Hypothesen bilden (Top-3 statt 30 Checks)

Nach dem Scope Check formulieren Sie maximal drei Hypothesen. Jede Hypothese muss testbar sein. Das verhindert zufälliges „Herumprobieren“.

• Hypothese A: WAN/ISP Problem (Path-down, Loss, Flaps)
• Hypothese B: Routing Problem (Default, Neighbor down, Leak/Blackhole)
• Hypothese C: VPN/NAT/MTU Problem (SA up, no traffic; MTU/MSS)

Phase 4: Hypothesen testen (kurze Tests, klare Interpretationen)

Testen Sie Hypothesen in der Reihenfolge mit der höchsten Wahrscheinlichkeit und dem größten Impact. Vermeiden Sie invasive Änderungen, bis Sie eine Hypothese bestätigt haben.

Testblock A: WAN/ISP (Link up vs. Path down)

• Prüfen: Interface Status, Errors/Drops, Track/IP SLA
• Interpretation: Track up aber keine Erreichbarkeit → falsches SLA Target oder Upstream-Problem

show ip interface brief
show interfaces counters errors
show ip sla statistics
show track
show ip route 0.0.0.0
traceroute 1.1.1.1

Testblock B: Routing (Convergence, Flaps, Blackholes)

• Prüfen: Neighbor Status, Route Summary, Logs
• Interpretation: wiederkehrende Flaps → Stabilität/CPU/Policy/Layer-1 prüfen

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

Testblock C: VPN/NAT (SA up, aber kein Traffic)

• Prüfen: IPsec Counter, Session Detail, NAT Stats/Translations
• Interpretation: SAs vorhanden, Counter 0 → Routing/No-NAT/Selector/MTU prüfen

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

Testblock D: MTU/MSS (Performance, Abbrüche, „nur manche Apps“)

• Prüfen: DF-Ping, Interface MTU, Queue Drops
• Interpretation: DF-Ping fail bei groß → MSS-Clamp/PMTUD/ICMP prüfen

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

Phase 5: Fix/Workaround validieren (Post-Checks und Traffic Path)

Jeder Fix braucht Post-Checks. Sonst bleibt unklar, ob der Incident wirklich gelöst ist oder nur „gerade ruhig“. Validieren Sie immer End-to-End.

• Post-Checks: gleiche Basis wie Pre-Checks (vergleichbar)
• Traffic Path: traceroute/ping zu definierten Targets
• Stabilität: Beobachtungsfenster ohne Flaps/Errors

CLI: Post-Fix Verification Pack

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 logging | last 50
show processes cpu sorted

Phase 6: Dokumentieren und verhindern (RCA & Preventive Actions)

Nach Restore beginnt Problem Management: Was war die Ursache, warum war die Erkennung spät, und welche Maßnahme verhindert Wiederholung? Das senkt Incident-Rate nachhaltig.

• RCA: Root Cause + Contributing Factors + Evidence
• Preventive Actions: Templates, Monitoring-Alerts, UAT-Erweiterung
• Governance: Change-ID, Review-Regeln, Drift-Control

Evidence-Standard: Was jede Eskalation enthalten sollte

Eskalationen werden schnell, wenn Evidence vollständig ist. Definieren Sie ein Standardpaket für ISP-, Vendor- oder L3-Eskalationen.

• Zeitstempel: show clock + NTP Status
• Linkzustand: Interface Status + Errors/Drops
• Servicepfad: Default Route, Track/IP SLA, traceroute
• VPN/Routing: Neighbor/SA Status, relevante Logs

CLI: Escalation Evidence Pack (Copy/Paste)

show clock
show ntp status
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip sla statistics
show track
traceroute 1.1.1.1
show crypto ipsec sa
show ip ospf neighbor
show bgp summary
show logging | last 150

Typische Fehler im Troubleshooting und wie Sie sie vermeiden

Diese Fehler verlängern MTTR besonders häufig. Nutzen Sie sie als „Anti-Checkliste“.

• Zu früh an der Konfiguration drehen, ohne Baseline und Hypothese
• Link up = Service up annehmen (Path-down ignorieren)
• VPN SA up = VPN funktioniert annehmen (Traffic Counter ignorieren)
• Nur Router prüfen, aber Provider/Firewall-Demarkation nicht klären
• Keine Dokumentation: Evidence fehlt, RCA wird Spekulation

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.