Site icon bintorosoft.com

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

Red Snapper

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.

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.

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.

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

Typische Transport-Root-Causes

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

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

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

KeepaliveInterval = 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.

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

Sichere Recovery bei Policy/Parameter-Problemen

Fehler, die den Debug unnötig verlängern

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.

Outbound-Links: Standards und vertiefende Referenzen

Checkliste zum Kopieren: BGP Session Down schnell einordnen

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