Cisco Router Incident Response: Vorgehen bei Routing Loops, Flaps oder Blackholes

Routing-Loops, Flaps und Blackholes gehören zu den kritischsten Incidents in Enterprise-Netzen mit Cisco-Routern: Sie erzeugen breite Ausfälle, Micro-Outages oder „funktioniert manchmal“ Symptome und eskalieren schnell durch Control-Plane-Last (CPU) und LSA/BGP-Updates. Ein wirksames Incident-Response-Vorgehen priorisiert deshalb Stabilisierung vor Root Cause: zuerst den Loop/Flap stoppen, dann die Ursache sauber eingrenzen, anschließend korrigieren und mit Evidence dokumentieren. Dieser Leitfaden zeigt ein praxistaugliches Vorgehen inklusive CLI-Snapshots, Entscheidungslogik und sicheren Mitigation-Schritten.

Begriffe im Incident: Loop vs. Flap vs. Blackhole

Die Symptome ähneln sich, die Gegenmaßnahmen unterscheiden sich. Die schnelle Einordnung spart Minuten und reduziert Folgeschäden.

• Routing Loop: Pakete kreisen zwischen Routern (TTL sinkt, CPU/Links steigen)
• Flap: Route/Neighbor wechselt wiederholt (Instabilität, Micro-Outages)
• Blackhole: Route existiert, aber Traffic wird verworfen oder findet keinen Rückweg

Typische Indikatoren

• Loop: traceroute zeigt Wiederholung, ICMP time-exceeded, TTL-Events
• Flap: Logs zeigen wiederkehrende Neighbor up/down, Route add/remove
• Blackhole: Route vorhanden, aber Ping/Session scheitert, oft asymmetrisch

Incident-Priorität: Wann Routing-Incidents P1 sind

Routing-Incidents werden schnell P1, weil sie mehrere Services gleichzeitig betreffen. Definieren Sie klare Trigger, damit 24/7 Teams sofort richtig eskalieren.

• Mehrere Standorte oder zentrale Services betroffen
• Default-Route/Backbone instabil oder weg
• OSPF/BGP Sessions flappen breitflächig
• CPU hoch und Management eingeschränkt

Sofortmaßnahme: Quick Snapshot (vor jeder Änderung)

Erzeugen Sie zuerst Evidence. Danach stabilisieren. Ohne Snapshot verlieren Sie die Ursachenindikatoren in Minuten.

show clock
show ip interface brief
show interfaces counters errors
show ip route summary
show ip route 0.0.0.0
show ip cef summary
show processes cpu sorted
show logging | last 100
show ip ospf neighbor
show bgp summary

Stabilisierung (Containment): Loop/Flap stoppen, ohne blind zu ändern

Containment hat Vorrang. Ziel ist, die Instabilität zu beenden und das Netz „atmen“ zu lassen. Wählen Sie die minimalinvasive Maßnahme, die den Schaden stoppt.

• Wenn ein einzelner Neighbor flapt: betroffenen Link isolieren (Interface shutdown als letztes Mittel)
• Wenn BGP Policy fehlerhaft: Neighbor temporär dämpfen/abschalten (kontrolliert)
• Wenn OSPF unerwartete Adjacencies: passive-interface korrigieren (Change-gate beachten)
• Wenn Loop durch Redistribution: betroffene Redistribution stoppen/rollback

CLI: Schnelle Stabilitätschecks

show logging | include OSPF|BGP|LINEPROTO|LINK-
show ip ospf neighbor
show bgp summary
show processes cpu sorted

Routing Loop Response: Diagnose und Mitigation

Loops entstehen häufig durch fehlende Summaries, falsche Redistribution oder asymmetrische Default-Strategien. Im Incident ist das Ziel: den Kreis identifizieren und den Loop-Pfad unterbrechen.

Diagnose-Schritte

• Traceroute zum Ziel: Wiederholungen identifizieren (Hop-Pattern)
• CEF-Check: zeigt, wohin der Router forwardet
• Routing-Check: welche Route gewinnt (longest prefix, AD, metric)
• Logs: Interface/Neighbor Events korrelieren

CLI: Loop-Diagnose (Copy/Paste)

traceroute 10.10.20.10
show ip route 10.10.20.0 255.255.255.0
show ip cef 10.10.20.10 detail
show ip cef summary
show logging | include time-exceeded|OSPF|BGP

Mitigation-Optionen (typisch)

• Falsche Route (AD/Metric): temporär Route preferieren oder fehlerhafte Route entfernen
• Redistribution-Loop: Redistribution stoppen oder Filter korrigieren
• Summarization-Fehler: Summary korrigieren (vorher prüfen, ob kein Blackhole entsteht)

Routing Flaps Response: Ursachen isolieren, Flap-Quelle finden

Flaps sind oft ein Symptom von Layer1/2 Instabilität oder aggressiven Timern, aber auch von Policy-Fehlern (BGP) oder unkontrollierten Neighbors (OSPF). Im Incident ist die wichtigste Frage: „Was flapt zuerst?“

Diagnose-Schritte

• Flap-Art: Interface flapt oder nur Neighbor flapt?
• Scope: einzelner Link oder viele Neighbors gleichzeitig?
• Ressourcen: CPU-Spike korreliert mit Flap (SPF/Update-Storm)
• Provider: bei WAN-Flaps Circuit/Carrier prüfen

CLI: Flap-Diagnose

show interfaces counters errors
show ip interface brief
show ip ospf neighbor
show bgp summary
show logging | include LINEPROTO|LINK-|OSPF|BGP
show processes cpu history

Mitigation-Optionen

• Interface flapt: Layer1/2 fixen (Kabel/SFP/Port), ggf. Backup-Link aktiv
• OSPF flaps ohne Interface-Down: Neighbor-Kontrolle (passive-interface) prüfen
• BGP flaps: max-prefix/policy/keepalive prüfen, Provider eskalieren

Blackhole Response: Forwarding ja, aber Traffic kommt nicht an

Blackholes sind tückisch, weil Routing „gesund“ wirken kann. Häufige Ursachen sind Null-Routen durch Summaries, asymmetrische Pfade bei stateful Komponenten oder fehlende Rückrouten.

Diagnose-Schritte

• Route vorhanden? (Longest prefix match prüfen)
• CEF Forwarding zeigt Next-Hop, aber Ping scheitert
• Rückweg prüfen: existiert Return Route auf Gegenseite?
• Stateful Pfad: Firewall/NAT asymmetrisch?

CLI: Blackhole-Diagnose

show ip route 10.10.20.0 255.255.255.0
show ip cef 10.10.20.10
ping 10.10.20.10 repeat 10
traceroute 10.10.20.10

Typischer Blackhole-Fall: Summary mit Null0

Summaries werden häufig mit Null0 abgesichert. Wenn jedoch Teilnetze fehlen oder falsch beworben werden, entsteht ein Blackhole. Prüfen Sie Summaries und die Existenz der Subnetze.

show ip route | include Null0
show ip route 10.10.20.0 255.255.255.0

Entscheidungslogik: Minimalinvasiv zur Stabilität

In P1-Incidents ist die beste Maßnahme oft die, die Instabilität schnell stoppt und rückgängig gemacht werden kann. Nutzen Sie eine klare Entscheidungskette statt spontane Änderungen.

• Wenn Interface instabil: physische Ursache priorisieren, Backup-Link nutzen
• Wenn Policy-Change kurz zuvor: Rollback bevorzugen
• Wenn Routing-Storm: Nachbar-/Redistribution-Quelle isolieren
• Wenn asymmetrisch: Pfad-Symmetrie wiederherstellen (Policy/FW/NAT prüfen)

Provider- und Stakeholder-Eskalation: Evidence, die immer benötigt wird

Routing-Incidents benötigen schnelle, belastbare Evidence. Das verkürzt Provider-Tickets und reduziert Diskussionen.

• Zeitstempel (show clock), NTP Status
• Betroffene Prefixes, Next-Hops (show ip route, show ip cef)
• Neighbor-Status (OSPF/BGP) und Flap-Logs
• Interface Errors/Drops (Layer1/2 Indikatoren)
• Circuit-ID/Providerdaten bei WAN-Bezug

CLI: Evidence-Kompakt (Copy/Paste)

show clock
show ntp status
show ip interface brief
show interfaces counters errors
show ip route summary
show ip route 0.0.0.0
show ip route 10.10.20.0 255.255.255.0
show ip cef 10.10.20.10 detail
show ip ospf neighbor
show bgp summary
show logging | last 100
show processes cpu sorted

Post-Incident: Was zwingend dokumentiert werden muss

Damit der Incident nicht wiederkehrt, müssen Ursache, Fix und Prävention in Standards zurückfließen. Das ist Teil von Continuous Improvement und Governance.

• Root Cause: Layer1/2, Policy, Redistribution, Summarization, Provider
• Fix: konkrete Konfigänderung (Change-ID), Peer-Review
• Prevention: Template-Update, passive-interface Standard, Filterpflicht, Monitoring-Alarme
• PIR-KPIs: Flap-Rate, Convergence-Zeit, MTTR, Anzahl betroffener Services

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.