Site icon bintorosoft.com

Troubleshooting-Runbook für Cisco-Router im 24/7-Betrieb: Struktur und Beispiele

Red Snapper

Ein Troubleshooting-Runbook für Cisco-Router im 24/7-Betrieb macht Incident-Response reproduzierbar: Es reduziert MTTR, verhindert „trial-and-error“ im Change-Fenster und sorgt dafür, dass auch Junior-Teams stabile Entscheidungen treffen. Ein gutes Runbook trennt Triage (schnell stabilisieren) von Root-Cause-Analyse (nachgelagert), definiert Eskalationspfade und liefert Copy/Paste-Checks mit klaren Interpretationshinweisen. Dieses Dokument zeigt eine praxistaugliche Runbook-Struktur und konkrete Beispiele für die häufigsten Störungen: Internet weg/langsam, VPN-Abbrüche, Routing-Flaps, hohe CPU und Packet Drops.

Runbook-Struktur: Standardabschnitte für 24/7

Im 24/7-Betrieb ist Konsistenz wichtiger als Vollständigkeit. Nutzen Sie für jeden Incident-Typ die gleiche Struktur, damit Stress nicht zu Fehlern führt.

Incident-Triage: Quick Snapshot (immer zuerst)

Der Quick Snapshot erzeugt einen konsistenten Datenstand, bevor Änderungen gemacht werden. Speichern Sie Outputs mit Zeitstempel und Ticket-ID.

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

Interpretationshilfe: Was der Quick Snapshot bedeutet

Der Snapshot ist nur nützlich, wenn Sie ihn schnell interpretieren können. Diese Indikatoren helfen bei der ersten Entscheidung.

Runbook 1: Internet „weg“ (Standort offline)

Ziel ist zuerst, den Ausfalltyp zu unterscheiden: Link down, Path down oder interne Segmentierung/DNS. Danach folgt die schnellste Mitigation (Failover, Provider-Ticket, Rollback).

Triage-Schritte

CLI (Internet down)

show ip interface brief
show ip route 0.0.0.0
ping 1.1.1.1 repeat 10
traceroute 1.1.1.1
show ip sla statistics
show track
show ip nat translations
show logging | include LINEPROTO|LINK-|IPSLAs

Mitigation (sicher, typisch)

Runbook 2: Internet „langsam“ (Latenz, Packet Loss, Congestion)

Langsamkeit ist meist Congestion oder Layer1/2 Errors. Ziel ist, Drops/Queues zu finden, QoS/Traffic-Spitzen zu identifizieren und kurzfristig zu stabilisieren.

Triage-Schritte

CLI (Performance)

show interfaces counters errors
show interfaces | include output drops|queue
show policy-map interface
show ip sla statistics
ping 1.1.1.1 repeat 20
show processes cpu sorted

Mitigation

Runbook 3: VPN-Abbrüche (Site-to-Site instabil)

VPN-Abbrüche entstehen häufig durch Path-Instabilität, Rekey/DPD Probleme oder MTU/MSS. Ziel ist, SA-Status, Paketzähler und Log-Hinweise zu prüfen und zwischen „VPN“ und „WAN“ zu trennen.

Triage-Schritte

CLI (VPN)

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show logging | include IKEV2|IPSEC|CRYPTO
show ip sla statistics
show interfaces counters errors

Mitigation

Runbook 4: Routing-Probleme (OSPF/BGP Flaps, Default fehlt)

Routing-Flaps sind im 24/7-Betrieb kritisch, weil sie Micro-Outages erzeugen. Ziel ist, Neighbor-Status, Logs und Interface-Stabilität zu prüfen und Instabilitätsquellen zu isolieren.

Triage-Schritte

CLI (Routing)

show ip route 0.0.0.0
show ip route summary
show ip ospf neighbor
show bgp summary
show logging | include OSPF|BGP|LINEPROTO|LINK-
show interfaces counters errors

Mitigation

Runbook 5: Hohe CPU / Router „träge“ (Control Plane Stress)

Hohe CPU kann aus Routing-Stürmen, Control-Plane-Scans oder Crypto/QoS Last entstehen. Ziel ist, Top-Prozesse zu identifizieren, Logs zu prüfen und Control Plane zu schützen.

Triage-Schritte

CLI (CPU)

show processes cpu sorted
show processes cpu history
show logging | last 100
show policy-map control-plane

Mitigation

Runbook 6: Segmentierungs-/Policy-Probleme (ACL/NAT „bricht Apps“)

Nach Changes an ACL/NAT sind „Apps kaputt“ häufig. Ziel ist, zu prüfen, ob die Policy-Matrix eingehalten ist, ob DNS/NTP fehlt und ob NAT/No-NAT korrekt greift.

Triage-Schritte

CLI (Policy)

show access-lists
show ip nat statistics
show ip nat translations
show logging | include DENY|ACL
show crypto ipsec sa

Mitigation

Eskalationspfad: Welche Evidence ein 24/7 Ticket immer enthalten muss

Eskalation funktioniert nur mit belastbaren Daten. Definieren Sie Minimum Evidence, das jedes Ticket (Provider/NetEng/SOC) enthalten muss.

CLI: Evidence-Kompakt (Copy/Paste)

show clock
show ntp status
show ip interface brief
show interfaces counters errors
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 100

Post-Incident: Was im PIR aus dem Runbook zurückfließen muss

Ein Runbook ist lebendig. Nach jedem größeren Incident sollten Erkenntnisse in Templates, Monitoring und Policies zurückgeführt werden, damit die gleiche Störung seltener wird.

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

Sie erhalten

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.

Exit mobile version