Site icon bintorosoft.com

Routing Instabilität: Flapping erkennen, dämpfen und root-cause finden

Red Snapper

Retro computer with monitor mouse and keyboard. Business concept. 3d render illustration.

Routing-Instabilität („Flapping“) ist einer der häufigsten Gründe für schwer erklärbare Netzwerkprobleme: kurze Paketverluste, wechselnde Pfade, Microloops und CPU-Spikes – ohne dass ein Link dauerhaft down ist. Flapping kann auf Layer 1/2 beginnen (optische Fehler, Duplex, Microbursts), durch Control-Plane-Themen verstärkt werden (BFD/IGP Timer, CoPP, CPU) oder aus dem Routing selbst kommen (Redistribution, Policy, fehlerhafte Summaries). Ein professionelles Vorgehen trennt daher drei Ziele: Flapping schnell erkennen, Impact kurzfristig dämpfen und anschließend die Root Cause sauber beweisen.

Was genau ist Flapping?

Flapping bedeutet: ein Zustand wechselt wiederholt zwischen „up“ und „down“ oder zwischen „preferred“ und „not preferred“. Im Routing kann das ein Interface sein, ein IGP-Neighbor, eine BGP-Session oder eine Route in der RIB/FIB.

Warum Flapping so gefährlich ist

Ein einzelnes Flap-Ereignis ist oft harmlos. Wiederholte Flaps erzeugen aber Flooding, SPF-Stürme, Rekeys und Queueing. Dadurch entstehen Symptome, die wie „WAN langsam“ oder „Applikation kaputt“ wirken.

Erkennen: Flapping in 60 Sekunden sichtbar machen

Du brauchst schnelle Indizien: Logs, Neighbor-States, Interface-Counters, Routing-Events. Der Trick ist, nicht nur „ist up“, sondern „wie oft war es in den letzten Minuten down?“ zu prüfen.

Interface-Flaps

show logging | include LINEPROTO|LINK-|Interface
show interfaces | include protocol|CRC|drops|error
show ip interface brief

IGP-Flaps

show ip ospf neighbor
show isis neighbors
show logging | include OSPF|ISIS|ADJCHG

BGP-Flaps

show ip bgp summary
show logging | include BGP|NEIGHBOR|ADJCHG

Flapping quantifizieren: Messfenster statt Bauchgefühl

Professionelles Troubleshooting arbeitet mit Zeitfenstern. Du definierst t1/t2 und misst: wie viele Events, wie viele Drops, wie viel CPU. So kannst du später Root Cause beweisen und Maßnahmen priorisieren.

Denkmodell

FlapRate = Events Zeit

Impact kurzfristig dämpfen: Stabilität gewinnen, bevor du tief debugst

Wenn Flapping Nutzer-Impact erzeugt, ist „Stop-the-bleeding“ legitim. Ziel ist, die Instabilität zu begrenzen, ohne die Root Cause zu verschleiern. Die wichtigsten Dämpfer sind: Failover kontrollieren, Timer nicht zu aggressiv, und flappende Links aus dem Transit nehmen.

Drain via OSPF Cost (Beispiel)

interface gigabitEthernet0/1
 ip ospf cost 10000

IS-IS Overload (Beispiel)

router isis CORE
 set-overload-bit

OSPF SPF Throttle (Beispiel)

router ospf 10
 timers throttle spf 50 200 5000

Root Cause finden: Layered Approach (L1 → L7)

Die häufigste Falle ist, sofort am Routing zu drehen, obwohl die Ursache physisch ist. Ein sauberes Vorgehen geht von unten nach oben: erst Link-Qualität, dann L2/L3-Adjacencies, dann Policies/Features.

Layer 1/2: Physische und Link-Qualität

show interfaces <int>
show controllers <int>
show interfaces <int> | include CRC|error|drops

Layer 3: Neighbor-Parameter und Consistency

show ip ospf interface <int>
show isis interface <int>
show bfd neighbors details

Routing-Policy/Features: Redistribution, Tracking, PBR

show ip route summary
show ip sla statistics
show track
show route-map
show ip policy

IGP-spezifisch dämpfen: Flooding und SPF-Stürme begrenzen

Wenn die Root Cause nicht sofort beseitigt werden kann, musst du IGPs stabil halten. Das heißt: Throttling, Area/Level-Design sauber, und „laute“ Quellen wie Redistribution streng kontrollieren.

BGP-spezifisch dämpfen: Session-Stabilität und Route Churn

BGP-Flapping ist oft ein Symptom von Underlay-Instabilität. Trotzdem kannst du BGP-spezifisch stabilisieren: Timer nicht zu aggressiv, BFD nur wo sinnvoll, und Prefix-Limits/Policies korrekt.

Evidence Capture: Flapping beweisen (für Post-Mortem/TAC)

Wenn Flapping wiederkehrend ist, brauchst du Beweise mit Zeitfenstern: Logs, Counterstände, Neighbor-Events. Das erleichtert Provider-Tickets und interne RCA.

Evidence Pack

show clock
show logging | last 300
show interfaces <int> | include protocol|CRC|drops|error
show ip ospf neighbor
show isis neighbors
show ip bgp summary
show processes cpu sorted
show ip route summary

Quick-Runbook: Flapping erkennen, dämpfen, Root Cause finden

Diese Sequenz ist als operativer Ablauf gedacht: erst identifizieren, dann stabilisieren, dann sauber eingrenzen.

! Erkennen
show logging | include LINEPROTO|LINK-|OSPF|ISIS|BGP|ADJCHG
show ip interface brief
show interfaces | include CRC|drops|error
show ip ospf neighbor
show isis neighbors
show ip bgp summary

! Dämpfen (nur wenn nötig, Change kontrolliert)

show processes cpu sorted

show policy-map control-plane

show ip sla statistics

show track


! Eingrenzen

show ip ospf interface 

show bfd neighbors details

show route-map

show ip policy

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

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