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

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.

• Interface-Flap: Link/Line protocol toggelt
• Neighbor-Flap: OSPF/IS-IS/BGP Neighbor geht up/down
• Route-Flap: ein Prefix wird wiederholt installiert/entfernt
• Path-Flap: Next-Hop wechselt (ECMP/Tracking/Policy)

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.

• IGP: LSA/LSP Flooding und SPF-Recomputes
• BGP: Session resets, Route churn, CPU/Memory-Last
• VPN: Rekey/DPD-Stürme, MTU/MSS-Fehlersymptome
• Data Plane: Microloops, Drops, Latenzspikes

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

$\text{FlapRate}=\frac{\text{Events}}{\text{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.

• Flappenden Link drainen (IGP cost erhöhen oder Overload setzen)
• BFD weniger aggressiv, wenn WAN jittery ist
• OSPF SPF/LSA Throttling gegen Stürme
• CoPP prüfen, damit Control Plane nicht kollabiert

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

• CRC/Errors, Flaps, Optik/Transceiver, Kabel
• Duplex/Speed-Mismatch (bei Copper)
• Microbursts/Queue Drops, die Control-Plane beeinträchtigen

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

Layer 3: Neighbor-Parameter und Consistency

• MTU-Mismatch, Auth-Mismatch, Area/Level mismatch
• Timer zu aggressiv (BFD/Hello), Jitter im WAN
• Asymmetrie und uRPF-Interaktionen

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

Routing-Policy/Features: Redistribution, Tracking, PBR

• Route Redistribution erzeugt Route churn
• IP SLA Tracking instabil (Probe-Ziel ungeeignet)
• PBR/ACL/NAT beeinflusst Return-Path und erzeugt „scheinbares Flap“

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.

• OSPF: SPF/LSA Throttling, Stub/NSSA, Summarization
• IS-IS: Overload bei Wartung, Summaries, L1/L2 sauber
• Beide: flappende Links nicht im Backbone „laut“ machen

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.

• Underlay zuerst stabilisieren (Interface/IGP)
• BFD konservativ im WAN, aggressiv nur im Core
• Prefix-Limits verhindern „Route Flood“ bei Fehlern

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

• 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.