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

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.

• L1/L2-Issue-indikativ: Interface-Flaps, Errors (CRC/FCS), steigende Drops/Discards, Optikwerte außerhalb Margin, LACP-Member wechseln, Congestion am Port, gleichzeitige Probleme bei mehreren Sessions auf demselben Bundle/Port/Linecard.
• Policy-Issue-indikativ: BGP bleibt „physisch“ stabil (Interface up, keine Errors), aber Session wird durch Protokoll-/Policy-Logik zurückgesetzt: Max-Prefix überschritten, Konfigurationsänderung, RPKI-Invalid-Policy greift, TTL Security/MD5/TCP-AO Probleme, fehlerhafte Route-Map verursacht BGP-Notification oder Soft-Reconfiguration eskaliert.

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:

• Flap-Frequenz: passiert es alle paar Sekunden, alle paar Minuten oder sporadisch?
• Korrelation: korreliert der Flap mit Port-Counter-Spikes, LAG-Events, CPU-Spitzen oder Changes?
• Scope: flappt nur eine Session oder mehrere Sessions auf demselben Interconnect gleichzeitig?

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

$\mathrm{Flap}\_\mathrm{Rate}=\frac{N\_\mathrm{flaps}}{T\_\mathrm{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)

• Port-Status und Flap-Historie: Link up/down Ereignisse in denselben Zeitfenstern wie BGP-Flaps sind ein starker Hinweis.
• Fehlerzähler: CRC/FCS, Symbol Errors, alignment errors, input errors, output errors.
• Optik (DOM/DDM): Rx/Tx-Power, Temperatur, Laser Bias, sowie bei modernen Interfaces Pre-FEC/Post-FEC-Indikatoren (plattformabhängig).
• Auto-Negotiation/Speed/Duplex: selten im Backbone, aber an bestimmten Edges relevant; Mismatches erzeugen subtile Fehler.

Layer 2 (LAG, MTU, Drops, Queueing)

• LACP/LAG-Member-Health: Member flappen? Ein einzelner „schlechter“ Member kann intermittierende Paketverluste erzeugen, während das Bundle „up“ bleibt.
• MTU-Checks: MTU-Mismatch kann TCP-Probleme verursachen, die Keepalives beeinflussen (besonders bei zusätzlichen Encapsulations). Prüfen Sie End-to-End-MTU bis zum Peer.
• Congestion und Drops: Output Drops, Tail Drops, Discards durch Shaper/Policer. Wenn Drops am Peering-Port zeitgleich mit Flaps steigen, ist L2/L1 wahrscheinlich beteiligt.

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:

• Hold Timer Expired / Keepalive Timeout: kann durch Paketverlust (L1/L2/Congestion) entstehen, aber auch durch CPU-Überlast oder Control-Plane-Policing.
• TCP Reset / Connection Reset by Peer: oft Policy/Daemon/Config-getrieben (z. B. Session-Schutz), aber auch möglich bei Transportproblemen.
• BGP Notification: deutet häufig auf Protokoll-/Policy-Probleme hin (z. B. Bad Message, Auth Failure, Capability Mismatch).
• Cease / Administrative Shutdown: häufig durch Max-Prefix-Mechanismen, Security-Policy oder geplante Changes.

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.

• Indikatoren: Prefix-Count-Spike, Max-Prefix-Logmeldungen, Session fällt immer bei ähnlicher Prefix-Anzahl.
• Folgeeffekt: Session kommt hoch, lernt Prefixes, überschreitet Limit, fällt wieder – zyklisch.

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

• Indikatoren: Session fällt nach einem Change-Window, nur bestimmte Nachbarn betroffen, Best-Path- oder Export-Samples verändern sich abrupt.
• Typische Ursachen: falsche Prefix-Listen, falsche Reihenfolge von Policy-Statements, „catch-all“-Regeln, unerwartete Community-Interpretation.

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

• CRC/FCS steigt: auch wenn der Link „up“ bleibt, führen Fehler zu Retransmits und Keepalive-Verlust.
• Pre-FEC steigt: besonders bei 100G/400G kann der Link lange „irgendwie“ laufen, bevor er kippt.
• Temperatur-/Power-Schwankungen: periodische Flaps (z. B. tagsüber/ nachts) können auf physische Einflüsse hindeuten.

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.

• Indikatoren: Output Drops/Discards, Queue-Längen-Spitzen, starke Zeitabhängigkeit (Peak).
• Abgrenzung: Congestion ist L2/Data-Plane, kann aber wie Policy wirken, wenn nur Control-Traffic betroffen ist.

LAG-Member-Flaps und Hashing-Nebenwirkungen

• Indikatoren: LACP-Events, ein Member zeigt Errors, andere nicht; Traffic- und Loss-Muster wirken „random“.
• Praxisproblem: Die BGP-Session kann über einen bestimmten Member gehasht werden. Flappt dieser Member, flappt „nur BGP“, während der Restverkehr evtl. stabil erscheint.

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.

• Wenn mehrere Sessions gleichzeitig flappen (gleicher Port, gleiche Linecard, gleiche IX-Fabric, gleicher LAG): L1/L2 zuerst prüfen.
• Wenn nur eine Session flappt und Port-Counter sauber sind: Policy/Session-Hardening/Neighbor-spezifische Faktoren prüfen.
• Wenn Down-Reason „Max-Prefix“ oder „Cease“ enthält: Policy-Issue hoch priorisieren.
• Wenn Down-Reason „Hold Timer Expired“ ist: Transport (Loss/Congestion) und Control-Plane-Load parallel prüfen.

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:

• Hold Timer Expired ohne Link-Errors: Keepalives werden nicht rechtzeitig verarbeitet.
• CPU-Spikes während Update-Stürmen: z. B. nach Routing-Events oder bei DDoS/Scanning.
• Policer-Hits auf BGP/TCP: Sessions sind instabil, obwohl Traffic-Ports „gesund“ wirken.

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.

• Loopback-Ping/Transporttest: testen Sie die IP-Erreichbarkeit des Peers (und ggf. des direkt verbundenen Interfaces) mit stabilen Intervallen. Packet Loss im selben Zeitfenster wie Flaps spricht für Transport/Congestion.
• Prefix-Count-Sampling: loggen Sie die Prefix-Anzahl kurz vor dem Flap. Wiederholt sich ein bestimmter Schwellenwert, ist Max-Prefix ein Hauptverdächtiger.
• Policy-Diff: wenn Flaps nach einem Change-Window begannen, vergleichen Sie die aktuelle Policy-Version gegen die letzte bekannte stabile Version.
• Session-Hardening-Check: TTL Security, Auth, MD5/TCP-AO konsistent? Ein einzelner Parameter-Mismatch kann zyklische Flaps erzeugen.

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.

• Stabile Interconnect-Hygiene: Optik sauber, MTU standardisiert, LAG-Member überwacht, klare Alarmierung auf Pre-FEC/Errors.
• Max-Prefix mit Warnschwellen: nicht nur Hard-Limit; früh warnen, damit Sie handeln können, bevor die Session fällt.
• RPKI-Rollout kontrolliert: „invalid = reject“ erst nach Monitoring-Phase, klare Ausnahmeprozesse für Partner.
• Policy-Versionierung und Tests: Export/Import-Samples vor und nach Changes vergleichen; staged rollouts statt Big Bang.
• CoPP/Control-Plane-Design: BGP/BFD/ICMP müssen zuverlässig durchkommen; Policer nicht „zu eng“ konfigurieren.
• Alerting auf Down-Reason: Alarmierung sollte zwischen Hold Timer, Cease, Notification und Admin Down unterscheiden.

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

• Timeline: Flap-Rate, Startzeitpunkt, Korrelation zu Changes oder Peak-Last.
• Scope: nur eine Session oder mehrere Sessions auf demselben Port/LAG/Router?
• L1/L2: Link-Flaps, Errors, Optikwerte, LAG-Member, Drops/Discards, MTU.
• BGP Down-Reason: Hold Timer, Notification, Cease, Reset by peer.
• Prefix-Counts: Spikes, Einbrüche, Max-Prefix-Events.
• Security/Hardening: TTL Security, Auth (MD5/TCP-AO), ACL/CoPP-Hits.
• CPU/Control Plane: CPU-Spikes, Queueing, Policer-Zähler.
• Hypothese testen: kurzer Transporttest und Policy-/Prefix-Sampling im selben Zeitfenster wie der Flap.

Outbound-Links für Standards und vertiefende Informationen

• RFC 4271: Border Gateway Protocol 4 (BGP-4)
• RFC 7908: Klassifikation von BGP Route Leaks
• RFC 6811: BGP Prefix Origin Validation (RPKI)
• RFC 5082: Generalized TTL Security Mechanism (GTSM)
• RFC 5925: TCP Authentication Option (TCP-AO)
• IANA IPv4 Special-Purpose Registry (für Bogon-/Reserved-Filter-Kontext)
• IANA IPv6 Special-Purpose Registry (für Bogon-/Reserved-Filter-Kontext)

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.