Troubleshooting unter Zeitdruck: Vorgehensmodell für kritische Router-Outages

Kritische Router-Outages sind selten „kompliziert“ – sie sind meist unübersichtlich, laut und zeitkritisch. Unter Druck passieren die häufigsten Fehler: planloses Herumklicken, mehrere Changes gleichzeitig, fehlende Baseline-Daten und zu spätes Rollback. Ein gutes Vorgehensmodell kombiniert Incident-Disziplin (Scope, Kommunikation, Stop-the-bleeding) mit einem technischen Fast-Path (Layer-Checks, Routing, Policies) und klaren Abbruchkriterien. Dieses Runbook ist dafür gedacht, in echten Major Incidents als Leitplanke zu dienen.

Erste Minute: Stabilisieren, Scope festlegen, Freeze aktivieren

Das Ziel der ersten Minute ist nicht „Root Cause“, sondern Stabilität und klare Verantwortung. Du willst vermeiden, dass parallel weitere Änderungen die Lage verschlimmern.

• Incident-Lead bestimmen (eine Person koordiniert)
• Change-Freeze: keine weiteren Changes ohne Lead-Freigabe
• Scope: welche Standorte/Services sind down (LAN, WAN, VPN, Internet)?
• Startzeit und letzte Änderung (Change/Deploy/Provider) notieren

5-Minuten-Fast-Path: „Ist es Link, Routing oder Policy?“

Die schnellste technische Einordnung ist eine Dreifachprüfung: Link/Interface, Routing/Default Route, Policy (ACL/NAT/VPN). Diese drei Bereiche decken die meisten Outages ab.

• Link: Interface down, Duplex/Errors, Provider-Hand-off
• Routing: Default Route weg, IGP/BGP down, CEF/Next-Hop
• Policy: ACL blockt, NAT kaputt, VPN SAs down, CoPP droppt

Fast-Path Commands (Copy & Paste)

show clock
show ip interface brief
show interfaces | include protocol|CRC|drops|error
show ip route | include Gateway|0.0.0.0
show ip route summary
show ip cef 8.8.8.8
show ip access-lists
show ip nat statistics
show crypto isakmp sa
show crypto ipsec sa
show policy-map control-plane
show logging | last 100

Stop-the-bleeding: Sofortmaßnahmen mit hohem Return

Wenn der Impact groß ist, priorisierst du Wiederherstellung (Restore Service) vor Perfektion. Du suchst nach reversiblen, low-risk Maßnahmen, die Traffic schnell wieder freigeben.

• Rollback des letzten Changes (wenn zeitlich korreliert)
• Failover aktivieren (Backup-ISP, Floating Default, HA-Gateway)
• Temporär restriktive ACL entschärfen (nur wenn klarer Lockout)
• VPN neu triggern (SAs löschen) bei klaren Rekey-Problemen

HA/Failover Schnellcheck

show standby brief
show track
show ip sla statistics
show ip route | include Gateway|0.0.0.0

IPsec „sauber neu verhandeln“ (kontrolliert)

clear crypto sa
clear crypto isakmp

Underlay zuerst: „Komme ich überhaupt raus?“

Bei Internet-/WAN-Outages ist Underlay-Konnektivität die Basis. Prüfe, ob du deinen Next-Hop, Provider-Gateway und ein externes Ziel erreichst – mit Source-Interface, damit du den Pfad wirklich testest.

ping <isp-next-hop> source <wan-ip>
ping 8.8.8.8 source <wan-ip>
traceroute 8.8.8.8 source <wan-ip>

Routing unter Zeitdruck: Default Route, Neighbors, CEF

Wenn der Link up ist, aber Traffic nicht läuft, ist Routing fast immer der nächste Kandidat. Prüfe Default Route, IGP/BGP-Neighbor-Status und CEF-Entscheidung für ein kritisches Ziel.

• Default Route vorhanden und zeigt auf erreichbaren Next-Hop
• OSPF/EIGRP/BGP Nachbarn up?
• CEF zeigt den erwarteten Outgoing-Interface/Next-Hop?

show ip route | include Gateway|0.0.0.0
show ip ospf neighbor
show ip eigrp neighbors
show ip bgp summary
show ip cef <critical-destination-ip>

Policy unter Zeitdruck: ACL/NAT/VPN in 3 Checks

Policies sind oft die Ursache nach Changes. Unter Druck prüfst du zuerst „blockt etwas offensichtlich?“, dann „sieht NAT normal aus?“ und zuletzt „stehen IPsec SAs und steigen Counters?“.

ACL: Richtung, implicit deny, Counters

show run | include access-group
show ip access-lists

NAT: Translations entstehen?

show ip nat statistics
show ip nat translations

VPN: Phase 1/2 und Counters

show crypto isakmp sa
show crypto ipsec sa

Symptom-Mapping: Schnell von Beobachtung zu Ursache

Diese Muster helfen, ohne langes Grübeln die nächste Hypothese zu wählen.

• Interface down/down: Layer 1/Provider/Cabling
• up/down: L2/Encapsulation, Provider-Fehler, Duplex/Clocking
• Default Route fehlt: Routing/Tracking/BGP/Static
• Ping Next-Hop ok, Internet nicht: Upstream/Policy/MTU/DNS
• NAT-Translations 0: NAT-Regel/inside-outside/ACL blockt
• ISAKMP leer: UDP/500/4500 blockt oder PSK/Policy mismatch
• IPsec encaps steigt, decaps 0: Rückweg/ACL/NAT/Remote Routing
• CPU hoch, Control-Plane Drops: CoPP/Scan/Flood

Kommunikation: Status-Updates ohne Spekulation

Unter Zeitdruck ist Kommunikation Teil der technischen Arbeit. Kurze, faktenbasierte Updates verhindern Eskalationschaos und helfen, externe Teams (Provider, DC) effizient einzubinden.

• Was ist betroffen (Scope) und seit wann?
• Was ist bestätigt (Fakten), was ist Hypothese?
• Nächster Schritt und ETA nicht raten, sondern „next check“ nennen
• Wenn Provider involviert: Ticket-ID, Messwerte, Traceroutes

Rollback-Disziplin: Abbruchkriterien definieren

Der häufigste Fehler ist „zu lange debuggen“, obwohl ein Rollback den Service sofort wiederherstellt. Definiere daher früh, wann du zurückrollst: z. B. wenn ein Change in Zeitnähe steht und keine schnelle Fix-Option sichtbar ist.

• Letzter Change in Zeitfenster? → Rollback priorisieren
• Mehrere Hypothesen ohne Fortschritt? → Rollback
• Wiederherstellung vor Root Cause (RCA später)

Rollback-Schnellpfade

copy startup-config running-config
reload
copy scp: running-config

Nach Stabilisierung: Datensicherung für RCA (ohne weiteres Risiko)

Wenn der Service zurück ist, sichere Zustandsdaten, bevor sie durch Timer/Flaps verschwinden. Das ist die Basis für eine saubere RCA, ohne „im Incident noch alles umzubauen“.

show tech-support
show logging | last 500
show ip route
show ip bgp summary
show crypto ipsec sa
show interfaces | include CRC|drops|error
copy running-config scp:

Minimal-Runbook: 10 Kommandos für den ersten Durchlauf

Diese zehn Kommandos liefern dir unter Zeitdruck die wichtigsten Fakten zu Link, Routing, Policy, VPN und CPU.

show ip interface brief
show interfaces | include protocol|CRC|drops|error
show ip route | include Gateway|0.0.0.0
show ip cef 8.8.8.8
show ip access-lists
show ip nat statistics
show crypto isakmp sa
show crypto ipsec sa
show policy-map control-plane
show logging | last 100

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.