Site icon BintoroSoft PDF Tools

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

Red Snapper

Computer technology 3D illustration. Computation of big data center. Cloud computing. Online devices upload and download information. Modern 3D illustration. 3D rendering

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.

Typische Indikatoren

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.

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.

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

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)

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

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

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

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.

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.

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.

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