Site icon bintorosoft.com

BGP-Session-Flap: L1/L2-Issue vs. Policy-Issue unterscheiden

Red Snapper

Futuristic computer lab equipment in a row generated by artificial intelligence

Ein „BGP-Session-Flap“ ist für NOC- und Backbone-Teams ein Alarmsignal mit hoher Priorität: Wenn eine BGP-Nachbarschaft wiederholt hoch- und runtergeht, verlieren Sie nicht nur Routen, sondern oft auch Stabilität im gesamten Edge- oder Interconnect-Segment. Das Hauptkeyword „BGP-Session-Flap“ beschreibt dabei nicht die Ursache, sondern das Symptom. In der Praxis stehen hinter Flaps meist zwei Klassen von Ursachen: ein L1/L2-Issue (physische oder link-layer Probleme wie Optik-Degradation, LAG-Member-Flaps, MTU-Mismatches, Drops, Congestion) oder ein Policy-Issue (z. B. Max-Prefix-Trigger, RPKI-Policy, Session-Schutzmechanismen, Konfigurationsdrift, fehlerhafte Route-Maps, aggressive Timer). Die Herausforderung: Beide Ursachenklassen können sich ähnlich anfühlen – insbesondere wenn „BGP down“ als einziger Alarm sichtbar ist. Dieser Artikel liefert ein praxisnahes Vorgehen, um bei einem BGP-Session-Flap belastbar zu unterscheiden, ob der Ursprung auf Layer 1/2 oder in Routing-Policy und Control-Plane liegt. Sie erhalten ein Diagnose-Playbook, typische Indikatoren, Messpunkte und Entscheidungslogik, die auch bei vielen Sessions und großen Netzen skalieren.

Was ist ein BGP-Session-Flap – und warum ist die Unterscheidung so wichtig?

BGP basiert auf einer TCP-Verbindung zwischen zwei Nachbarn. Ein Flap bedeutet: Diese TCP-Verbindung (und damit die BGP-Session) wird beendet und erneut aufgebaut. Jeder Flap kann Routen withdrawen, Best-Path-Entscheidungen ändern und dadurch Traffic umlenken. Der betriebliche Schaden ist oft größer als der eigentliche Ausfall, weil Flaps Kaskaden auslösen können: zusätzliche BGP-Updates, höhere CPU-Last, FIB-Programmierungsdruck, kurzzeitige Blackholes und instabile Pfade. Technische Grundlagen zu BGP finden Sie in RFC 4271 (BGP-4).

Die Unterscheidung „L1/L2 vs. Policy“ ist entscheidend, weil die Maßnahmen komplett anders sind. Bei L1/L2 müssen Sie Linkgesundheit, Optik, LAG und Transportpfad stabilisieren. Bei Policy müssen Sie Import/Export-Regeln, Max-Prefix, RPKI-Validierung oder Session-Sicherheitsmechanismen analysieren. Wer hier falsch abbiegt, verliert Zeit – und erhöht durch ungezielte Mitigation (z. B. Timer aggressiver machen) häufig sogar die Flap-Rate.

Die zwei Flap-Welten: So sehen L1/L2-Issues und Policy-Issues typischerweise aus

Ein schneller Einstieg gelingt, wenn Sie die Symptome in zwei typische Muster sortieren. Das ist keine Garantie, aber ein belastbarer Startpunkt.

Wichtig: Auch L1/L2 kann „nur BGP“ sichtbar machen, wenn andere Sessions nicht existieren oder Monitoring lückenhaft ist. Deshalb müssen Sie immer von der Session nach unten (Layer) und nach oben (Policy) prüfen.

Schritt 1: Timeline statt Momentaufnahme – Flaps korrekt einordnen

Ein einzelner Snapshot „Session down“ ist selten aussagekräftig. Entscheidend ist die Timeline:

Für die Flap-Frequenz können Sie eine einfache Rate definieren, um Incident-Schwere objektiver zu machen:

Flap_Rate = N_flaps T_window

N_flaps ist die Anzahl der Session-Resets im Beobachtungsfenster T_window (z. B. 15 Minuten). Eine hohe Flap-Rate spricht oft für physische Instabilität oder einen aggressiven Schutzmechanismus, der immer wieder triggert.

Schritt 2: L1/L2-Baseline am Interconnect – der schnellste Beweis

Wenn Sie L1/L2 ausschließen oder bestätigen wollen, müssen Sie am Interconnect anfangen, nicht bei BGP-Logs. Prüfen Sie konsequent:

Physik (Layer 1)

Layer 2 (LAG, MTU, Drops, Queueing)

Schritt 3: BGP-Session-Mechanik verstehen – welche Down-Reason zeigt auf welche Ursache?

Ein BGP-Session-Flap ist nicht nur „down“. Die Down-Reason ist oft der wichtigste Hinweis. Typische Ursachenklassen:

Wenn Sie in Ihren Geräten Logs oder Telemetrie zur Session-Beendigung haben, priorisieren Sie diese Daten. Bei eBGP-Sessions ist zusätzlich ein Blick auf Schutzmechanismen wie GTSM/TTL Security sinnvoll; Referenz: RFC 5082.

Policy-Issue-Detektoren: Die klassischen Trigger, die wie L1/L2 aussehen können

Viele Policy-Issues erzeugen Session-Flaps, ohne dass L1/L2 etwas zeigt. Die wichtigsten Kandidaten:

Max-Prefix überschritten

Max-Prefix schützt vor Route Leaks oder versehentlichen Full-Table-Announces. Wird der Grenzwert überschritten, kann die Session je nach Konfiguration gewarnt, gedämpft oder heruntergefahren werden. Das sieht dann wie ein „BGP-Flap“ aus, obwohl Link und TCP prinzipiell funktionieren.

Für Route-Leak-Problemklassen als Hintergrund eignet sich RFC 7908.

RPKI-Validierung und „Invalid“-Policy

RPKI kann Routen als „valid“, „invalid“ oder „not found“ klassifizieren. Eine harte „invalid = reject“-Policy kann bei bestimmten Partnern oder bei fehlerhaften ROAs zu massiven Route-Änderungen führen. Das verursacht zwar nicht immer einen Session-Flap, kann aber Session-Resets triggern, wenn Policies dynamisch umgebaut werden oder wenn ein Peer darauf reagiert. Referenz: RFC 6811.

GTSM/TTL Security, MD5 oder TCP-AO

Wenn TTL Security oder TCP-Authentisierung nicht konsistent ist, kann die Session hochkommen und sofort wieder fallen (oder gar nicht stabil werden). Besonders tückisch: einzelne Pakete werden verworfen, was wie Loss aussieht, aber eigentlich Security-Policy ist. TCP-AO ist in RFC 5925 beschrieben.

Import/Export-Policy-Fehler, Route-Maps und Community-Drift

L1/L2-Issue-Detektoren: Wenn die Session wegen Transport instabil wird

Bei L1/L2-Issues ist die BGP-Session Opfer des Transportproblems. Häufige Muster:

Optik-Degradation und „leise“ Fehler

Congestion am Interconnect

Congestion ist ein unterschätzter Flap-Treiber: Wenn Control-Pakete in denselben Queues wie Massentraffic landen oder wenn Policer zu aggressiv sind, werden Keepalives gedroppt. Das führt zu Hold Timer Expired, obwohl Layer 1 „gesund“ wirkt.

LAG-Member-Flaps und Hashing-Nebenwirkungen

Entscheidungsbaum: In welcher Reihenfolge Sie prüfen sollten

Für schnelle Incident-Isolation hilft ein standardisierter Entscheidungsbaum. Das Ziel ist nicht perfekte Wahrheit, sondern eine belastbare Priorisierung.

Ein praktischer Weg, L1/L2 „hart“ zu falsifizieren, ist: Link-Health über ein Zeitfenster gegen Flaps korrelieren. Wenn Errors/Drops exakt mit Flaps korrelieren, ist das ein starker Beweis für L1/L2. Wenn nicht, rückt Policy in den Fokus.

Control-Plane-Policing und CPU: Die „dritte“ Ursache zwischen L2 und Policy

In vielen Netzen gibt es eine Grauzone: Die Session flappt nicht wegen physischem Linkproblem und nicht wegen bewusster Policy, sondern weil die Control Plane überlastet ist oder weil CoPP/Policer BGP/BFD/ICMP falsch behandeln. Das sieht oft so aus:

Für die Diagnose ist wichtig: Control-Plane-Probleme sind meist systemisch. Wenn mehrere Sessions auf einem Gerät gleichzeitig instabil werden, prüfen Sie CPU, CoPP-Zähler, Queueing und eventuelle Nebenwirkungen durch Telemetrie oder ACL-Änderungen.

Praktische Tests: Wie Sie Hypothesen schnell verifizieren

Statt lange zu diskutieren, helfen gezielte Tests, die Hypothesen „L1/L2“ oder „Policy“ schnell stützen.

Best Practices, um BGP-Session-Flaps grundsätzlich zu vermeiden

Ein großer Teil der Flaps ist vermeidbar, wenn BGP am Edge wie ein standardisiertes Produkt betrieben wird: wenige Template-Klassen, klare Guardrails, gute Telemetrie.

Minimal-Checkliste fürs NOC: In 15 Minuten zur richtigen Richtung

Outbound-Links für Standards und vertiefende Informationen

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