BGP Session Down: Schneller Debug (Transport vs. Policy)

Ein „BGP Session Down“ gehört zu den Incident-Typen, bei denen Minuten zählen: Sobald die BGP-Nachbarschaft abreißt, verschwinden Routen, Traffic wird umgeleitet, und je nach Design kann ein kompletter Standort oder ein ganzer Internet-Edge „blind“ werden. In der Praxis ist das Problem jedoch nicht immer BGP selbst. Sehr häufig ist die Ursache im Transport (TCP/179 kommt nicht durch, Interface/VRF/Route fehlt) oder in einer Policy- bzw. Konfigurationsänderung (Authentication, TTL, Update-Source, Prefix-Limits, Filter, Route-Maps). Für einen schnellen Debug ist es deshalb entscheidend, sofort sauber zu trennen: Ist die BGP Session Down wegen Transportproblemen (Layer 1–4) oder wegen Policy/Parametern (BGP-Features und Kontrolllogik)? Wenn Sie diese Unterscheidung früh treffen, sparen Sie Zeit, vermeiden hektische Maßnahmen wie globale Prozess-Resets und kommen schneller zu einer stabilen Recovery. Dieser Artikel liefert eine praxisorientierte Vorgehensweise für den NOC- und Produktionsbetrieb: Welche Checks Sie in welcher Reihenfolge durchführen, welche typischen Root Causes hinter Transport vs. Policy stecken, wie Sie Flaps von echten „harten“ Ausfällen unterscheiden, und welche Recovery-Schritte Sie sicher anwenden können, ohne zusätzliche Instabilität ins Netz zu bringen.

Was „BGP Session Down“ technisch bedeutet

BGP (Border Gateway Protocol) läuft über TCP (Port 179). Eine Session ist nur dann stabil, wenn die TCP-Verbindung steht, beide Seiten BGP-Open/Keepalive austauschen und die Session im Zustand „Established“ bleibt. „Down“ kann dabei sehr unterschiedlich sein: Die Session kommt gar nicht erst hoch (z. B. „Active/Connect“), sie geht nach kurzer Zeit wieder runter (Flap), oder sie bleibt etabliert, aber verliert Updates (selten, dann eher „Degradation“). Für die Grundlagen ist die maßgebliche Referenz RFC 4271 (BGP-4). Für BGP über TTL-Security/Generalized TTL Security Mechanism (GTSM) ist RFC 5082 relevant.

• Transport-Ebene: TCP/179 muss end-to-end funktionieren (Routing, VRF, ACL, NAT, MTU, Paketverlust).
• BGP-Parameter: ASNs, Neighbor-IP, Update-Source, Authentication (MD5/TCP-AO), TTL/Hops, Address-Family.
• Policy-Ebene: Import/Export-Filter, Prefix-Limits, Max-Prefix, Route-Maps/Policies, Communities.

Die wichtigste Unterscheidung: Transport vs. Policy

Für den schnellen Debug ist die Frage nicht „Warum ist BGP down?“, sondern: „Kommt TCP/179 überhaupt zustande?“ Wenn TCP nicht zustande kommt oder instabil ist, sind Policy-Diskussionen meist Zeitverschwendung. Wenn TCP stabil ist, aber BGP nicht etabliert bleibt, sind häufig Parameter-/Policy-Themen oder Kontrollplane-Mechanismen (Hold Timer, Keepalive, Authentication, Max-Prefix) die Ursache.

• Transport-Problem (häufig): Keine Erreichbarkeit, kein TCP-Handshake, asymmetrische Filter, falsche VRF, fehlende Route zum Neighbor, MTU/Fragmentation-Probleme.
• Policy/Parameter-Problem (häufig): Falsches Remote-AS, falsche Update-Source, TTL/GTSM-Mismatch, Authentication mismatch, Max-Prefix Shutdown, fehlerhafte AFI/SAFI-Konfiguration.

Triage in 3 Minuten: Fragen, die den Debug sofort fokussieren

Bevor Sie in Logs versinken, stellen Sie drei operative Fragen. Diese geben Ihnen eine klare Richtung und helfen, den Blast Radius zu begrenzen.

• Scope: Ist nur eine Session betroffen oder mehrere? Mehrere gleichzeitige Ausfälle sprechen eher für Transport, Interface, VRF oder Control-Plane.
• Art des Peers: eBGP (z. B. Internet/Provider/IX) oder iBGP (intern)? eBGP ist häufiger durch Transport/Edge-ACL/NAT betroffen, iBGP häufiger durch Loopback-Routing/IGP/Update-Source.
• Change-Korrelation: Gab es kurz vorher eine Änderung an ACLs, VRFs, NAT, Interface, Policy, Prefix-Limit oder Authentication?

Transport-Debug: Schnell prüfen, ob TCP/179 das Problem ist

Wenn eine BGP Session Down ist, prüfen Sie zuerst den Transportpfad. Die meisten Fälle lassen sich hier bereits entscheiden: Entweder ist der Neighbor-IP nicht erreichbar, oder TCP/179 wird irgendwo gefiltert bzw. fällt durch State-/Policy-Regeln. Auch MTU-Themen können TCP instabil machen, insbesondere wenn MSS/Path-MTU-Discovery beeinträchtigt ist.

Transport-Checkliste

• IP-Erreichbarkeit: Ping/Traceroute zur Neighbor-IP (oder zur Loopback, wenn darüber peeringt wird). Wichtig: in der richtigen VRF/Source testen.
• Routing zur Peer-IP: Existiert eine stabile Route? Gibt es Recursion-Probleme bei Loopback-Peering (iBGP) oder bei eBGP über Loopback?
• TCP/179 erreichbar: Ist der Port auf dem Pfad offen (Firewall/ACL/Security-Policy)?
• Asymmetrie: Kann die Hinrichtung funktionieren, aber der Rückweg nicht? Asymmetrische Routen sind ein häufiger Session-Killer.
• MTU/MSS: Große BGP Updates können fragmentiert werden; wenn Fragmentierung oder PMTUD geblockt ist, sind Drops möglich.

Typische Transport-Root-Causes

• Interface/Link Instabilität: Flaps, CRC-Errors, optische Degradation; BGP fällt sekundär, weil TCP Pakete verliert.
• ACL/Firewall-Änderung: TCP/179 oder Rücktraffic (ephemerer Port) wird geblockt; oft nach „Security Hardening“ oder Change Freeze.
• Falsche VRF/Source: Tests laufen aus der falschen Routing-Instanz; BGP selbst nutzt aber eine andere.
• NAT/Stateful Middlebox: Timeouts oder Session-Tracking-Probleme führen zu sporadischen Resets.
• PMTUD/ICMP blockiert: Path MTU Discovery bricht, große TCP-Segmente werden gedroppt, BGP wirkt „unzuverlässig“.

Policy- und Parameter-Debug: Wenn Transport ok ist, aber BGP trotzdem nicht steht

Wenn IP-Erreichbarkeit und TCP/179 grundsätzlich funktionieren, konzentrieren Sie sich auf BGP-spezifische Parameter und Policies. Hier ist die größte Gefahr, dass man „Policy“ mit „Routing Policy“ verwechselt. Für das Zustandekommen einer Session sind vor allem Peer-Parameter relevant (Remote-AS, Local-AS, Update-Source, Authentication, TTL/GTSM, Address-Family). Import/Export-Filter beeinflussen meist nicht das „Established“, können aber indirekt durch Prefix-Limits oder durch Trigger-Mechanismen (z. B. Max-Prefix Shutdown) eine Session hart abschalten.

Parameter, die eine Session direkt verhindern

• Remote-AS falsch: Sehr häufiger Fehler nach Konfig-Drift oder Migration.
• Update-Source/Local Address falsch: Besonders bei iBGP/Loopback-Peering oder bei eBGP multihop.
• Authentication mismatch: MD5/TCP-AO-Key oder Methode passt nicht; Sessions bleiben in „Active/Connect“ oder werden sofort wieder getrennt.
• TTL/GTSM: TTL-Security erwartet bestimmte Hop-Anzahl; bei falscher TTL-Konfiguration werden Pakete verworfen.
• Address-Family deaktiviert: IPv4/IPv6 oder VPNv4/EVPN nicht aktiv; je nach Plattform wirkt das wie „Session up, aber keine Routes“ oder verhindert Establishment.

Policy-Themen, die Sessions abschießen können

• Max-Prefix/Prefix-Limit: Wenn der Peer mehr Prefixe sendet als erlaubt, kann die Session automatisch shutdown werden.
• Route-Policy-Fehler: Nicht zwingend Session Down, aber kann zu „kein Traffic“ führen, was als Down fehlinterpretiert wird.
• Community-basierte Steuerung: Falsche Community-Filter können die Route-Propagation komplett stoppen.

Hold Timer, Keepalive und warum „Timer“ häufig indirekt schuld ist

Eine BGP-Session bleibt etabliert, wenn Keepalives rechtzeitig ausgetauscht werden. Häufig ist ein Timer-Problem jedoch kein „falscher Wert“, sondern Paketverlust/Jitter oder Control-Plane-Policing, wodurch Keepalives nicht ankommen oder nicht verarbeitet werden. In der Praxis zeigt sich das als wiederkehrender Flap mit ähnlichem Timing.

Timer-Beziehung greifbar machen

$\mathrm{KeepaliveInterval}=\frac{\mathrm{HoldTime}}{3}$

Viele Implementierungen nutzen standardmäßig diese Relation (Keepalive ungefähr ein Drittel der Hold Time), wobei Konfiguration und Defaults je nach Plattform variieren können. Entscheidend operativ: Wenn Ihre Umgebung Paketverlustspitzen oder Policing auf Control-Traffic hat, sind aggressive Timer ein Flap-Verstärker.

Erkennungsmerkmale: Woran Sie Transport vs. Policy schnell unterscheiden

Im NOC helfen wenige, wiederkehrende Muster, um die Ursacheklasse zu erkennen, bevor Sie tief graben.

• „Active/Connect“ und kein Fortschritt: Häufig Transport (kein TCP) oder Authentication/Remote-AS verhindert Open-Handshake.
• Session kurz Established, dann sofort down: Häufig Authentication/Capabilities/Policy (z. B. Max-Prefix) oder TCP-Reset durch Middlebox.
• Mehrere Sessions gleichzeitig down: Häufig Underlay, Interface, VRF/Route-Ausfall, Firewall-Change oder Control-Plane-Event.
• Nur ein Peer betroffen, andere stabil: Häufig Peer-spezifische Parameter, Prefix-Limit oder ein einzelner Transportpfad.
• „Kein Routing“, aber Session Established: Häufig Routing Policy/AFI/SAFI/Filter, nicht Transport.

Recovery-Schritte: Stabilisieren ohne Folgeschäden

Recovery ist in BGP-Incidents besonders heikel, weil ein unkontrolliertes Neusetzen von Sessions oder Policies großflächige Route-Churn und Traffic-Shifts erzeugen kann. Ziel ist daher: Erst Stabilität im Underlay herstellen, dann BGP kontrolliert wieder aufbauen, danach Policy-Funktion prüfen. Ein „Session Up“ ist nur dann ein Erfolg, wenn Routen stabil sind und der Datenpfad plausibel ist.

Sichere Recovery bei Transport-Problemen

• Underlay priorisieren: Interface-Errors, Link-Flaps, MTU-Probleme, ARP/ND-Stabilität beheben.
• ACL/Firewall rollbacken oder gezielt fixen: TCP/179 und Rücktraffic sauber erlauben, State-Timeouts prüfen.
• Routing-Recursion reparieren: Bei Loopback-Peering sicherstellen, dass die Next-Hop-Erreichbarkeit stabil ist.

Sichere Recovery bei Policy/Parameter-Problemen

• Parameter synchronisieren: Remote-AS, Update-Source, TTL/GTSM, Authentication beidseitig prüfen und angleichen.
• Max-Prefix bewusst behandeln: Wenn ein Prefix-Limit greift, nicht „blind erhöhen“, sondern Ursache für Prefix-Anstieg klären.
• Änderungen schrittweise: Erst Session stabil, dann AFI/SAFI, dann Import/Export-Policy, dann Optimierung.

Fehler, die den Debug unnötig verlängern

• Nur auf BGP schauen, Transport ignorieren: Ohne TCP/179 bringt Policy-Debug nichts.
• Tests aus falscher VRF/Source: Ping klappt „irgendwie“, aber nicht aus der Instanz, die BGP nutzt.
• „Clear BGP“ als Reflex: Kann kurzfristig Symptome verschieben, aber erzeugt Route-Churn und kann die Lage verschlechtern.
• Max-Prefix wegkonfigurieren: Nimmt einen Schutzmechanismus aus dem Netz; besser Ursache (Leak) beheben.
• MTU/PMTUD übersehen: Besonders bei Firewalls/Overlays kann PMTUD blockiert sein und TCP instabil machen.

Prävention: So vermeiden Sie wiederkehrende BGP Session Down Incidents

Viele BGP-Ausfälle sind Wiederholer, weil Prozesse und Baselines fehlen. Prävention bedeutet: Transportpfade messbar stabil halten, Policies versioniert und überprüfbar machen und Schutzmechanismen (Max-Prefix, GTSM) richtig einsetzen, ohne False Positives zu erzeugen.

• Transport-Baselines: Interface-Errors, Drops, MTU/MSS, Latenz/Jitter und Paketverlust kontinuierlich beobachten.
• Konfig-Standards: Peer-Templates für eBGP/iBGP (Update-Source, TTL, Auth, Timer) und konsequentes Drift-Management.
• Policy-Review: Import/Export-Policy, Prefix-Limits und Communities regelmäßig prüfen, insbesondere vor größeren Rollouts.
• Change-Gates: ACL/Firewall/CoPP-Änderungen nur mit expliziten Tests für TCP/179 und Rückpfade.
• Schutzmechanismen sinnvoll einsetzen: GTSM/TTL-Security und Max-Prefix reduzieren Angriffsfläche und Leaks, brauchen aber saubere Ausnahmen und Monitoring.

Outbound-Links: Standards und vertiefende Referenzen

• RFC 4271 – BGP-4 (Session, Timer, Zustände, Nachrichten)
• RFC 5082 – GTSM (TTL Security) für BGP
• RFC 6286 – Autonomous-System-Wide Unique BGP Identifier

Checkliste zum Kopieren: BGP Session Down schnell einordnen

• Scope: Eine Session oder mehrere? Gleichzeitig betroffen → Transport/Underlay/Control-Plane wahrscheinlicher.
• Transport zuerst: Erreichbarkeit zur Peer-IP aus korrekter VRF/Source prüfen; TCP/179 und Rückpfad sicherstellen.
• Wenn Transport ok: Remote-AS, Update-Source, TTL/GTSM, Authentication, AFI/SAFI vergleichen.
• Flap-Muster prüfen: Rhythmus im Bereich Hold Time/Keepalive deutet auf Timer/Jitter/Policing hin.
• Max-Prefix prüfen: Wurde die Session wegen Prefix-Limit heruntergefahren? Ursache für Prefix-Anstieg klären.
• Recovery kontrolliert: Erst Ursache beheben, dann Session stabilisieren, danach Routen und Datenpfad verifizieren.
• Nacharbeit: Ticket mit Zeitlinie, Transport-Checks, Parametervergleich, Logs und getroffenen Maßnahmen dokumentieren.

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.