BGP Flapping: Root Cause zwischen Link, CPU und Policies

BGP Flapping ist eines der teuersten und nervigsten Fehlerbilder im Netzwerkbetrieb, weil es gleichzeitig die Control Plane belastet, Routing-Instabilität erzeugt und sich in Anwendungen wie ein „zufälliger“ Ausfall anfühlt: Verbindungen brechen ab, Latenz springt, Traffic nimmt Umwege, und Monitoring meldet wechselnde Erreichbarkeit. Anders als bei einem klaren Link-Down ist BGP Flapping oft ein Mix aus mehreren Ursachen, die sich gegenseitig verstärken. Ein instabiler physischer Pfad kann TCP-Retransmissions erhöhen, dadurch steigt die CPU-Last, dadurch verzögern sich Keepalives, dadurch läuft der Hold Timer ab – und am Ende sieht es so aus, als würde „BGP spinnen“. Ebenso häufig ist das Gegenteil: Der Link ist stabil, aber Policies oder Limits (Max-Prefix, Route-Maps, Communities) provozieren Resets oder Updates, die die Control Plane überlasten. Professionelles BGP Troubleshooting bedeutet deshalb, die Root Cause zwischen Link, CPU und Policies sauber zu trennen – mit einer festen Reihenfolge, evidenzbasierten Checks und klaren Mitigation-Schritten, die den Betrieb stabilisieren, ohne Sicherheitsmechanismen blind abzuschalten. Dieser Artikel zeigt Ihnen, wie Sie BGP Flapping systematisch diagnostizieren, typische Muster erkennen und belastbare Fixes umsetzen, die auch bei Lastspitzen und Change-Events standhalten.

BGP Flapping verstehen: Was genau „flappt“ eigentlich?

Wenn eine BGP-Session „flappt“, wechselt sie wiederholt zwischen Established und einem niedrigeren Zustand (Idle/Connect/Active/OpenSent/OpenConfirm). Aus Sicht des Betriebs ist entscheidend: BGP läuft über TCP (Port 179). Ein Flap ist daher entweder ein Transport-/TCP-Problem, ein Control-Plane-Problem (Keepalives/Timer/CPU/CoPP) oder eine gezielt ausgelöste Session-Beendigung (Notification, Policy, Limit). Die Protokollgrundlagen beschreibt RFC 4271 (BGP-4).

• Transport-Flap: TCP-Verbindung bricht weg (Loss, Reset, Firewall-State, MTU/TCP-Fallback-Probleme).
• Timer-Flap: Hold Timer läuft ab, weil Keepalives nicht rechtzeitig ankommen (Delay/Loss/CPU/CoPP).
• Policy-/Limit-Flap: Session wird aktiv geschlossen (z. B. max-prefix exceeded, policy reject, auth fail).

Die goldene Reihenfolge: Erst Transport, dann Control Plane, dann Policy

Die häufigste Ursache für lange Incidents ist eine falsche Diagnose-Reihenfolge. Teams springen sofort in Route-Maps oder Communities, obwohl TCP instabil ist. Oder sie tun nur „ping“, obwohl TCP/179 und Keepalives die Wahrheit erzählen. Ein praxiserprobtes Vorgehen sieht so aus:

• Schritt 1: Flap-Typ klassifizieren: TCP-Reset/Timeout, Hold Timer Expired, Admin Reset, Max-Prefix, Notification.
• Schritt 2: Transport beweisen: TCP/179 stabil? Retransmissions? RST/FIN? MTU/Fragmentation?
• Schritt 3: Control Plane prüfen: CPU, CoPP/Policer, Input Queues, Keepalive-Jitter, BFD (falls genutzt).
• Schritt 4: Policies/Limits prüfen: Max-Prefix, Prefix-Filter, Route Refresh, große Update-Stürme, Auth/TTL/GTSM.

High-Signal Symptome: So lesen Sie BGP Flapping richtig

Ein „BGP down“ Alarm allein ist wenig wert. Entscheidend ist, warum die Session endet. Viele Plattformen liefern dafür klare Reason-Codes oder Log-Meldungen. Sammeln Sie diese vor jeder Änderung.

• Hold Timer Expired: deutet meist auf Loss/Delay/CPU/CoPP hin, selten auf „Policy“.
• TCP connection reset / connection refused: häufig Firewall/NAT/State oder Peer-Prozess/Daemon restart.
• Cease/Notification: der Peer beendet aktiv (z. B. policy, admin shutdown, capability mismatch).
• Max-Prefix exceeded: Limit triggert, oft durch Route Leak oder Policy-Fehler, nicht durch „BGP Instabilität“.
• Interface down / BFD down: Underlay/Link ist der erste Verdacht.

Für TCP-Verhalten, Retransmissions und Timer-Mechanik ist RFC 9293 (TCP) eine hilfreiche Referenz, weil viele BGP-Flaps am Ende TCP-Symptome sind.

Root Cause Domäne 1: Link und Transportpfad

Transportprobleme sind die häufigste Root Cause für echtes Flapping, besonders bei eBGP über WAN/Internet, bei Cross-Connects mit physischer Degradation oder bei asymmetrischen Pfaden durch Firewalls/NAT. Wichtig: Der Link kann „up“ sein und trotzdem so viele Errors/Drops haben, dass TCP instabil wird.

Physische Instabilität: Errors statt Auslastung

• CRC/Symbol Errors: beschädigte Frames werden verworfen, TCP retransmittet, BGP Keepalives kommen zu spät.
• Optics Drift: Rx Power/Temperatur/Bias schwanken, Link bleibt up, aber Qualität ist marginal.
• Duplex/Autoneg Mismatch: selten in modernen Setups, aber weiterhin möglich an Rändern oder Medienkonvertern.

Praxis-Hinweis: Wenn Sie BGP Flapping sehen, prüfen Sie immer auch Interface-Fehlerzähler, nicht nur die Link-Utilization. Congestion erzeugt typischerweise Drops/Queueing, echte CRC/Symbol Errors sind dagegen ein Layer-1/2-Thema.

TCP/179 wird gefiltert oder stateful „zerlegt“

• Firewall/NAT State Timeouts: wenn Keepalives zu selten sind oder State-Tables unter Druck stehen, wird die Session gekappt.
• Asymmetrische Pfade: Hinweg über Firewall A, Rückweg über Firewall B ohne State-Sync → sporadische Resets.
• Policy nur für UDP/ICMP: Ping ok, aber TCP/179 wird gedroppt oder gerate-limited.

MTU-/PMTUD-Fallen: „klein geht, groß floppt“

BGP-KEEPALIVEs sind klein. Deshalb kann eine Session zunächst stabil wirken und erst bei größeren Updates oder Route Refreshs flappen. Wenn große TCP-Segmente droppen (MTU-Blackhole, Fragmentation-Probleme, ICMP blockiert), steigen Retransmissions, der Throughput fällt, und irgendwann läuft der Hold Timer ab.

• Indiz: Flaps korrelieren mit Policy-Änderungen, Route Refresh oder „viele Updates“.
• Evidence: PCAP zeigt Retransmissions/Zero Window/TCP stalls; Firewall-Logs zeigen Fragment-/ICMP-Drops.
• Fix-Richtung: Pfad-MTU sauber, PMTUD ermöglichen; Overhead (VPN, QinQ, GRE/IPsec) berücksichtigen.

Für PMTUD-Grundlagen sind RFC 1191 (IPv4 PMTUD) und RFC 8201 (IPv6 PMTUD) relevant.

Root Cause Domäne 2: CPU, Control Plane und Queueing

Wenn Link und TCP grundsätzlich erreichbar sind, ist die Control Plane die nächste große Root-Cause-Domäne. BGP ist rechenintensiv: Updates verarbeiten, Policies anwenden, RIB/FIB aktualisieren, eventuell Routen reflektieren, Logs schreiben. Wenn CPU oder Control-Plane-Queues am Limit laufen, werden Keepalives verzögert oder gedroppt – und die Session flappt, obwohl der physische Pfad gesund ist.

Hold Timer Expired ist oft ein CPU-Signal

• CPU Peaks: Routing churn, große Update-Wellen, FIB programming, Nebenprozesse (Telemetry, Logging) oder Softwarebugs.
• Interrupt/SoftIRQ Pressure: besonders bei Software-Routern/VMs, wenn Pakete nicht schnell genug abgearbeitet werden.
• Queue Drops: Input Queues voll; Control-Plane Traffic wird verworfen.

Professioneller Ansatz: Korrelieren Sie Flap-Zeitpunkte mit CPU, Memory, Input Queue Drops und Control-Plane Countern. Wenn Flaps immer in Peak-Fenstern auftreten, ist das ein starkes Indiz für Ressourcen-/Queueing-Probleme, nicht für „BGP Konfig“.

CoPP/Policer: Schutz, der zur Ursache werden kann

Control Plane Policing (CoPP) ist sinnvoll, um die CPU vor Angriffen und Stürmen zu schützen. Falsch dimensioniert kann CoPP jedoch legitime BGP-Pakete drosseln – besonders bei Update-Stürmen, Route Refresh oder bei vielen Sessions gleichzeitig.

• Indiz: Drops in CoPP-Klassen für TCP/179 oder BGP; Flaps bei Update-Peaks.
• Fix-Richtung: CoPP so anpassen, dass BGP unter Worst-Case Update-Raten stabil bleibt, ohne Schutzwirkung zu verlieren.

Route Reflectors und große Tabellen: Skalierung als Trigger

• RR Overload: Ein RR spiegelt Updates an viele Clients; bei churn steigt CPU exponentiell.
• RIB-to-FIB Pressure: FIB-Programmierung kann verzögert sein; BGP bleibt zwar established, aber Keepalives leiden bei CPU-Engpässen.
• Garbage Collection/Memory Pressure: Prozesse pausieren; Keepalive-Planung wird instabil.

Root Cause Domäne 3: Policies, Limits und „selbst ausgelöste“ Flaps

Nicht jedes Flapping ist „instabiler Link“. Sehr häufig sind Flaps bewusst ausgelöst: ein Limit greift, eine Policy verwirft Updates, Auth/TTL Security blockt oder der Peer sendet Notifications. Diese Ursachen sind besonders wichtig, weil sie oft nach Changes auftreten und ohne Evidence schnell missverstanden werden.

Max-Prefix und Route Leaks: der Airbag, der knallt

Max-Prefix ist ein Sicherheitsnetz. Wenn es triggert, ist das meist ein Hinweis auf einen Route Leak oder eine unerwartete Policy-Änderung. Der typische Fehler ist, das Limit reflexartig zu erhöhen, statt die Leak-Quelle zu identifizieren.

• Indiz: Session geht established und resetet kurz danach; Logs zeigen „maximum prefix exceeded“.
• Fix-Richtung: Inbound Prefix-Filter prüfen, Leak-Quelle isolieren, Warnschwellen und Baselines nachziehen.

Auth- und TTL-Mechaniken: Flaps durch Schutzfunktionen

• TCP MD5 (BGP Auth): Key mismatch erzeugt Resets oder verhindert stabilen Aufbau; Referenz: RFC 2385 (TCP MD5).
• TTL Security (GTSM): blockt Pakete, wenn Hopcount nicht passt; Referenz: RFC 5082 (GTSM).
• eBGP multihop/Source Interface: falsche Source-IP oder falsche TTL-Konfiguration führt zu scheinbar „random“ Connect/Active Loops.

Policy-Churn: Route Refresh, Communities und große Update-Wellen

Auch ohne Leak können Policies Flapping indirekt verursachen, wenn sie Update-Churn erzeugen: z. B. ein Community-Change, der sehr viele Routen neu bewertet, oder ein Route Refresh, der einen Update-Sturm auslöst. Das ist kein „BGP Fehler“, sondern ein Kapazitäts- und Change-Management-Thema.

• Indiz: Flaps direkt nach Policy-Deployments, RR-Updates, Community-Rollouts.
• Evidence: Update-Rate hoch, CPU steigt, CoPP drops, Hold Timer Expired folgt.
• Fix-Richtung: Policy-Änderungen stufenweise, RR-Kapazität, Route Dampening nur bewusst, Update-Stürme durch Design reduzieren.

Die entscheidenden Trennmessungen: Link vs. CPU vs. Policy beweisen

Wenn Sie wenig Zeit haben, helfen Trennmessungen, die Root Cause schnell zuzuordnen. Ziel ist, nicht „alles zu prüfen“, sondern die Hypothesen zügig zu falsifizieren.

• Peer-Vergleich: Flappen mehrere Sessions auf demselben Gerät gleichzeitig? → eher CPU/CoPP/Transport-Edge. Flappt nur ein Peer? → eher Link/Peer/Policy spezifisch.
• Zeitkorrelation: Flaps exakt nach Change/Policy deploy? → eher Policy/Update-Churn. Flaps zu Peak-Zeiten? → CPU/Queueing oder Congestion.
• Transportbeweis: PCAP zeigt TCP Retransmissions/RST? → Transport. PCAP zeigt Notifications? → Policy/Capability/Auth.
• Update-Last: Prefix Counts/Update Rate springen vor dem Flap? → Leak/Policy/Refresh.
• Interface Health: CRC/Symbol Errors steigen parallel? → physisch. Nur Drops/Queue? → Congestion/Buffering.

PCAP als „Ground Truth“: Was Sie im Mitschnitt wirklich suchen

Ein kurzer Capture (gezielt, nicht stundenlang) kann in Minuten klären, warum eine Session endet. Besonders wertvoll sind BGP NOTIFICATIONs und TCP-Reset-Signale. Nutzen Sie Captures am Edge-Interface oder an einem Mirror-Port und konzentrieren Sie sich auf den Flap-Zeitpunkt.

• TCP Handshake: SYN/SYN-ACK/ACK stabil? Wiederholte SYNs? RST von welcher Seite?
• Retransmissions: steigen sie vor dem Hold Timer Expired?
• BGP OPEN/KEEPALIVE: kommen sie regelmäßig, oder gibt es Lücken?
• NOTIFICATION: Code/Subcode zeigt oft direkt die Ursache (z. B. Cease, Capability mismatch).

Für Capture- und Analysepraxis sind die Wireshark-Dokumentation und die tcpdump-Manpage gute Referenzen.

Mitigation ohne Blindflug: Stabilisieren, bevor Sie optimieren

Bei BGP Flapping ist es oft sinnvoll, zuerst zu stabilisieren, um die Auswirkung auf das Gesamtnetz zu reduzieren. Danach folgt die Root-Cause-Beseitigung. Entscheidend ist, Mitigation so zu wählen, dass Sie nicht das Sicherheitsnetz entfernen.

• Fehlerhaften Link isolieren: Wenn Evidence für physische Errors spricht, den betroffenen Pfad/Members kontrolliert drainen.
• Update-Churn reduzieren: Route Refresh/Policy-Deploy stufenweise, RR-Last begrenzen, ggf. temporär weniger Sessions aktivieren.
• CoPP anpassen statt deaktivieren: legitime BGP-Raten erlauben, aber Schutz gegen Flooding erhalten.
• Max-Prefix respektieren: nicht sofort erhöhen; erst Leak-Quelle finden. Warnschwellen nutzen, um früh zu reagieren.
• Timer nicht „blind“ erhöhen: kann Symptome kaschieren, aber Root Cause bleibt; nur als temporäre Stabilisierung mit klarer Rücknahme.

Hygiene und Baselines: Damit Flapping nicht wiederkehrt

Viele Flapping-Probleme sind wiederkehrend, weil Baselines fehlen. Ein robustes Setup kombiniert Observability, saubere Policies und Kapazitätsplanung.

• Session-Telemetrie: Flap-Rate, Hold Timer Expired Counts, Notification-Codes, Uptime-Verteilung.
• Transport-Telemetrie: TCP Retransmissions, RTT/Jitter zum Peer, Firewall-State-Exhaustion Signale.
• Control-Plane-Telemetrie: CPU, input queue drops, CoPP drops, update rate.
• Policy-Governance: versionierte Prefix-Lists/Route-Maps, Peer-Templates, automatische Drift-Checks.
• Limits: Max-Prefix mit Warnschwellen, Baseline für expected prefixes pro Peer.
• Change-Markierung: Policy- und Routing-Changes als Events in Monitoring, damit Korrelation sofort möglich ist.

Runbook-Baustein: BGP Flapping in 15 Minuten zur wahrscheinlichsten Root Cause

• Minute 0–3: Flap-Grund aus Logs sichern (Hold Timer Expired, TCP reset, Notification, max-prefix). Betroffene Peers zählen: einer oder viele?
• Minute 3–6: Transport prüfen: TCP/179 Reachability, Retransmissions, Firewall/NAT state, Interface Errors (CRC/Symbol) und Drops.
• Minute 6–9: Control Plane prüfen: CPU/Queue/CoPP drops, Update-Rate, RR/Edge-Last. Korrelieren Flaps mit Peak-Zeiten?
• Minute 9–12: Policy/Limits prüfen: max-prefix events, inbound/outbound filters, TTL/GTSM/Auth (MD5), Route Refresh/Policy deploy Timeline.
• Minute 12–15: Low-Risk Mitigation: fehlerhaften Pfad drainen, CoPP/Queueing stabilisieren, Leak eindämmen (Filter/Max-Prefix), danach Verifikation (Session Uptime stabil, update rate normal, keine Notifications).

Weiterführende Quellen für Standards und vertiefende Referenzen

• RFC 4271 für BGP-4 (FSM, Messages, Notifications)
• RFC 9293 für TCP (Retransmissions, Timer, Stabilitätsmechaniken)
• RFC 2385 für TCP MD5 Signatures (BGP Authentifizierung)
• RFC 5082 für TTL Security Mechanism (GTSM)
• RFC 1191 für PMTUD unter IPv4 (relevant bei MTU-Blackholes)
• RFC 8201 für PMTUD unter IPv6
• Wireshark Dokumentation für BGP/TCP-Forensik und Notification-Interpretation
• tcpdump Manpage für effiziente Captures im Incident

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.