Site icon bintorosoft.com

BGP Flapping: Root Cause zwischen Link, CPU und Policies

Red Snapper

Platform for hosting servers contemporary Internet contents. Rack housing server data storage hardware. Connected by a lot of network cables. Generative AI

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

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:

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.

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

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“

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.

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

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.

Route Reflectors und große Tabellen: Skalierung als Trigger

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.

Auth- und TTL-Mechaniken: Flaps durch Schutzfunktionen

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.

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.

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.

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.

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.

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

Weiterführende Quellen für Standards und vertiefende Referenzen

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:

Lieferumfang:

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.

 

Exit mobile version