BGP Session Troubleshooting: TCP, Auth, TTL, Policies und Limits

BGP Session Troubleshooting gehört zu den wichtigsten Fähigkeiten im Betrieb von WAN-, Provider- und Cloud-Hybrid-Netzen, weil ein einziger fehlerhafter BGP-Peer ganze Präfixgruppen „verschwinden“ lassen oder ungewollt über einen teuren/instabilen Pfad schicken kann. Gleichzeitig ist BGP als Protokoll sehr „ehrlich“: Wenn eine Session nicht hochkommt oder flappt, gibt es fast immer einen konkreten Grund – TCP/179 ist nicht erreichbar, Authentifizierung passt nicht, TTL/Hops sind falsch, Policies blockieren Updates oder Limits reißen die Session wieder herunter. Wer BGP Session Troubleshooting methodisch angeht, spart massiv Zeit: Statt blind zu „clear“-en oder Parameter zu drehen, prüfen Sie in einer festen Reihenfolge zuerst den Transport (TCP), dann die Sitzungsparameter (Auth, TTL, Timer), dann die Control-Plane-Stabilität (Keepalives, CPU/CoPP, BFD) und erst danach die Route-Policies (Import/Export, Communities, Prefix-Lists) sowie Schutzmechanismen wie Max-Prefix. Dieser Artikel liefert eine praxisnahe Tool- und Denkmethodik, um BGP-Sessions schnell einzuordnen und belastbar zu beweisen, wo die Ursache liegt – inklusive typischer Fehlerbilder, Evidence-Quellen und stabiler Baselines, damit BGP im Betrieb „langweilig“ bleibt.

Was eine BGP-Session wirklich ist: TCP plus Protokollzustand

BGP läuft über TCP (Port 179). Das klingt simpel, ist aber der wichtigste Debugging-Hinweis: Wenn TCP nicht stabil ist, kann BGP nicht stabil sein. Erst wenn der TCP-Handshake steht, startet BGP mit OPEN-Messages, handelt Capability-Parameter aus (z. B. Multiprotocol für IPv6, Route Refresh) und geht dann über KEEPALIVE/UPDATE in den Established-Zustand. Viele Teams springen sofort zu „Policies“, obwohl die Session nie über TCP hinauskommt.

• Transport: TCP/179, stateful, sensitiv für Loss/Latency/MTU
• BGP FSM: Idle → Connect → Active → OpenSent → OpenConfirm → Established
• Keepalive/Hold: Heartbeat-Mechanik, die Session bei Ausbleiben schließt
• Update-Exchange: erst im Established-Zustand relevant; Policies greifen hier

Für die normativen Grundlagen zu BGP-4 ist RFC 4271 die zentrale Referenz.

Die schnellste Entscheidung im Incident: „Session down“ oder „Session up, aber keine Routen“

Bevor Sie tiefer gehen, trennen Sie zwei Welten. Beide werden im Alltag fälschlich als „BGP Problem“ beschrieben, aber sie werden völlig unterschiedlich gelöst.

• Session down/flapping: Fokus auf TCP, Auth, TTL, Timer, Control Plane, CoPP/ACLs, Pfadinstabilität
• Session established, aber falsche/keine Routen: Fokus auf Import/Export-Policy, Next-Hop-Handling, Communities, Max-Prefix, Route Filtering

Wenn die Session nicht established ist, sind Route-Policies fast nie der erste Engpass. Umgekehrt: Wenn Established stabil ist, sind TCP/TTL oft bereits bewiesen „okay“ – dann lohnt der Blick auf Policy und Limits.

Transport zuerst: TCP/179 als primärer Gatekeeper

Weil BGP TCP nutzt, beginnt jedes saubere BGP Session Troubleshooting mit dem Nachweis, dass TCP/179 in beide Richtungen funktioniert. Hier entstehen die meisten „einfachen“ Ursachen: Firewall-Regeln, falsches Source-Interface, NAT, Asymmetrie oder MTU-Blackholes, die den TCP-Handshake oder spätere Segmente stören.

Typische TCP-Fehlerbilder

• Kein SYN/SYN-ACK: Routing/ACL/Firewall blockt, falsche Peer-IP, falsches Source-Interface
• Handshake klappt, Session bricht sofort: BGP OPEN wird abgelehnt (Auth/Capabilities/AS mismatch) oder TCP reset durch Policy
• Session flappt unter Last: TCP Retransmissions, Loss, MTU/Fragmentation, Control-Plane-Drops
• Nur ein Peer betroffen: selektiver ACL/Path/Provider-Edge Fehler oder einseitiges NAT

Evidence für TCP-Probleme

• Packet Capture: SYN/SYN-ACK/ACK sichtbar? TCP resets? Retransmissions?
• Firewall Logs: Drops auf TCP/179, asymmetrische Flows, state table timeouts
• Interface Counters: Drops/Errors (nicht nur Utilization)
• MTU-Indizien: große Segmente droppen, PMTUD-Feedback fehlt

Für TCP-Grundlagen und Verhalten bei Retransmissions ist RFC 9293 hilfreich.

Authentication: MD5 und „passt nicht“ ist meist eindeutig

Ein Klassiker im BGP Session Troubleshooting ist Authentifizierung. In vielen Umgebungen wird BGP mit TCP MD5 Signatures abgesichert (häufig „BGP MD5“ genannt). Wenn Keys oder Key-Handling nicht übereinstimmen, scheitert der Verbindungsaufbau oder die Session resetet sofort. Das Gemeine ist: Ein Teil der Tools zeigt nur „Active“ oder „Idle“, obwohl das Problem eigentlich ein Auth-Mismatch ist.

Typische Auth-Fehlerbilder

• Connect/Active Loop: TCP kommt nicht dauerhaft hoch oder wird sofort zurückgesetzt
• Log-Hinweise: „bad MD5 digest“, „authentication failure“, „TCP MD5 failed“ (vendorabhängig)
• Intermittent Flaps: bei Key-Rollovers ohne Überlappung oder inkonsistenten Key-Chains

Praxisregeln für sichere Auth-Baselines

• Key-Rollovers planen (überlappende Keys, klare Change-Fenster)
• Keying konsistent: gleiche Richtung (in/out), gleiche Key-ID/Chain-Logik (plattformabhängig)
• Logging aktiv: Auth-Failures müssen sichtbar sein, sonst wirkt es wie „TCP kaputt“

MD5 für TCP ist historisch in RFC 2385 beschrieben; moderne Diskussionen rund um stärkere Mechanismen existieren, aber im Betrieb ist MD5 weiterhin verbreitet.

TTL und Hop-Modelle: Warum eBGP „direkt“ ist und iBGP nicht

TTL-Probleme sind besonders häufig bei eBGP über nicht-direkt angeschlossene Peers (z. B. über Loopbacks, in VXLAN/EVPN- oder MPLS-Designs, oder bei Provider-Edges hinter einem Transit). Standardmäßig nutzt eBGP oft TTL=1, wodurch der Peer nur bei direkter Nachbarschaft funktioniert. Wird der Peer über mehr als einen Hop erreicht, muss das TTL-Modell angepasst werden (häufig als „ebgp-multihop“ bezeichnet) – und genau hier passieren Fehler: falscher Hopcount, falsche Source-Adresse, oder Security-Features wie GTSM/TTL Security, die unerwartet blocken.

Typische TTL-Fehlerbilder

• TCP SYN erreicht Peer nicht (oder kommt nicht zurück): TTL läuft ab, weil eBGP TTL=1 und Peer nicht direkt
• Session kommt nur in einem Standort hoch: unterschiedliche Hopcount-Realität, Anycast/ECMP
• TTL Security blockt: Peer sendet mit „falscher“ TTL (zu niedrig), wird verworfen

TTL Security (GTSM) richtig interpretieren

TTL Security Mechanism (GTSM) ist ein sehr sinnvolles Schutzfeature: Es akzeptiert BGP-Pakete nur, wenn die TTL nahe am Maximum liegt (typisch: 255 minus kleiner Margin). Damit verhindert man Angriffe aus der Ferne. Wenn GTSM aktiv ist, müssen aber Peer-Design und Hopcount konsistent sein. Sonst wirkt es wie „BGP down“, obwohl es ein bewusstes Schutzverhalten ist.

TTL Security ist in RFC 5082 beschrieben.

Timer und Stability: Keepalive, Hold, und warum Flaps selten „einfach so“ passieren

Wenn eine BGP-Session flappt, ist das oft ein Symptom für Transportinstabilität oder Control-Plane-Probleme, nicht für „zu kurze Timer“. Trotzdem sind Timer im Incident relevant, weil sie entscheiden, wie schnell eine instabile Verbindung als down gilt. Zu aggressive Hold Times können bei Microbursts, kurzzeitigem Loss oder CPU-Spikes zu unnötigen Resets führen.

Typische Timer-Fehlerbilder

• Hold Timer Expired: Keepalives kommen nicht rechtzeitig an (Loss/Delay/CPU)
• Häufige Resets zu Peak-Zeiten: Congestion, CoPP, Firewall state pressure
• Ein Peer flappt, andere stabil: selektiver Pfad oder Peer-Device überlastet

Stabile Timer-Baseline

• Timer nicht „auf Verdacht“ drastisch verkürzen
• Wenn schnelle Failure Detection nötig ist: BFD als Ergänzung prüfen (Design-abhängig)
• Control-Plane-Schutz so dimensionieren, dass Keepalives nicht gedroppt werden

Control Plane und Limits: CoPP, CPU, Queueing und Max-Prefix

BGP ist ein Control-Plane-Protokoll. Selbst wenn Links und TCP gesund sind, kann die Session instabil werden, wenn die Control Plane überlastet ist: CPU hoch, Input-Queues voll, oder CoPP/Policer drosselt BGP-Traffic. Zusätzlich gibt es bewusst konfigurierte Schutzmechanismen wie Max-Prefix, die eine Session bei zu vielen empfangenen Routen schließen können. In Incidents wird das oft als „BGP droppt zufällig“ wahrgenommen – tatsächlich ist es ein Schutz vor Route Leaks.

CoPP/Policer als versteckte Ursache

• Symptom: sporadische Keepalive/Update-Verluste, Hold Timer Expired, vor allem unter Last
• Evidence: CoPP Drops für BGP, Input queue drops, CPU peaks korrelieren mit Flaps
• Fix-Richtung: CoPP Profile anpassen, Control-Plane-Queueing prüfen, Ursachen für CPU-Spikes entfernen

Max-Prefix und Limits richtig interpretieren

• Symptom: Session geht Established, dann sofort reset (oder nach kurzem Update-Exchange)
• Evidence: Log „maximum prefix exceeded“ oder ähnliche Meldung; counters zeigen mehr received routes als erlaubt
• Fix-Richtung: Root Cause ist häufig ein Leak oder ein Policy-Fehler, nicht „Limit zu niedrig“

Policies: Wenn die Session steht, aber nichts Sinnvolles passiert

Wenn die BGP-Session established ist, sind Policies und Attribute die häufigste Ursache für „keine Routen“ oder „falscher Pfad“. Wichtig ist: Policies wirken in mehreren Stufen – Inbound (was wird akzeptiert), Decision Process (was wird bevorzugt), Outbound (was wird announced). Ein Fehler in einer einzigen Prefix-List oder Community-Regel kann komplette Services beeinflussen.

Typische Policy-Fehlerbilder

• Received Routes = 0: inbound filter zu strikt, falsche AFI/SAFI, falsches Peer-Template
• Advertised Routes = 0: outbound policy blockt, next-hop/route-map setzt unerwartete Attribute
• Route kommt, aber nicht im FIB: next-hop unreachable (IGP/recursive lookup), VRF mismatch
• Pfadwahl kippt: LocalPref/MED/AS-PATH Manipulation, Communities fehlen oder werden entfernt

Decision Process als Denkmodell

Sie müssen den kompletten Entscheidungsprozess nicht auswendig können, aber Sie sollten wissen, welche Attribute in der Praxis die größten Hebel sind: Local Preference (typisch iBGP), AS-PATH (typisch eBGP), MED (wenn relevant), und Policy-basierte Overrides. Für Standards und Detailtiefe ist RFC 4271 die Primärquelle.

TTL, TCP, Policy: typische Kombinationsfallen in realen Netzen

Viele BGP Incidents entstehen aus der Kombination mehrerer „kleiner“ Faktoren. Diese Muster helfen, schneller die richtige Stelle zu finden.

• Session klappt nur manchmal: ECMP/Anycast führt zu wechselndem Hopcount; TTL/GTSM-Policy passt nicht stabil
• Nur große Updates brechen: MTU/Fragmentation oder Firewall-Inspection; TCP retransmits steigen, Hold Timer läuft ab
• Session stable, aber Traffic blackholed: next-hop unreachable oder falscher next-hop-self; BGP ok, IGP/VRF nicht
• Session reset nach wenigen Sekunden: max-prefix, policy reject, oder Auth mismatch

PCAP und Forensik: Wie Sie BGP sauber beweisen

Wenn Sie Evidence für interne Postmortems oder Provider-Tickets brauchen, sind Captures unschlagbar. Sie sehen TCP Handshake, BGP OPEN/KEEPALIVE/NOTIFICATION und können exakt belegen, ob ein Reset vom Peer kam oder lokal ausgelöst wurde. Dabei reicht oft ein kurzer Capture am Edge-Interface oder auf einem Mirror-Port.

• TCP: SYN/SYN-ACK/ACK, Retransmits, RST/FIN, MSS/Windowing Hinweise
• BGP OPEN: ASNs, Router-ID, Hold Time, Capabilities (AFI/SAFI)
• NOTIFICATION: sehr wertvoll; zeigt, warum der Peer die Session beendet hat
• Timing: Keepalive-Intervalle, Hold Timer Verhalten unter Last

Für praktische Capture- und Analyseworkflows eignen sich die Wireshark-Dokumentation und die tcpdump-Manpage.

Sichere Baselines: Damit BGP-Sessions stabil und auditierbar sind

Das beste BGP Session Troubleshooting ist das, das Sie selten brauchen. Dafür helfen Baselines, die sowohl Sicherheit als auch Betriebsstabilität verbessern.

• Transport-Baseline: TCP/179 erlaubt, aber gezielt (ACLs), klare Source-IPs, dokumentierte NAT/Firewall-States
• Auth-Baseline: TCP MD5 oder andere Mechanismen konsistent, Key-Rollovers geplant, Logging aktiv
• TTL/GTSM: für direkte eBGP Peers TTL Security nutzen, für multihop klare Hopcount-Standards
• Limits: Max-Prefix mit Warnschwellen und klarer Leak-Response; nicht „zu hoch“, sondern sinnvoll pro Peer
• Policy-Governance: Prefix-Listen/Communities versioniert, Peer-Templates, automatische Drift-Checks
• Observability: Session Flaps, Hold Timer Expired, CoPP Drops, received/advertised route counts als Dashboards

Runbook-Baustein: BGP Session Troubleshooting in 15 Minuten

• Minute 0–3: Zustand klassifizieren: Session down/flapping oder established ohne Routen? Logs/Reason Codes sichern (Hold Timer, Notification, max-prefix).
• Minute 3–6: TCP/179 beweisen: Handshake sichtbar? RST/Timeout? Firewall/ACL/VRF/Source-Interface prüfen.
• Minute 6–9: Sitzungsparameter prüfen: Auth (MD5), TTL/ebgp-multihop/GTSM, Router-ID/ASN, Capabilities/AFI/SAFI.
• Minute 9–12: Stability prüfen: Keepalive/Hold, CoPP/CPU/Queue Drops, MTU/Fragmentation bei großen Updates, optional PCAP/Notification auswerten.
• Minute 12–15: Wenn Established: Policies/Limits prüfen (in/out filters, communities, max-prefix), Next-Hop Reachability (IGP/recursive). Fix minimal und kontrolliert, danach Verifikation (Session stabil, route counts plausibel, FIB forwardet).

Weiterführende Quellen für Standards und vertiefende Referenzen

• RFC 4271 für BGP-4 (FSM, OPEN/KEEPALIVE/UPDATE/NOTIFICATION, Decision Process)
• RFC 2385 für TCP MD5 Signatures (klassische BGP-Authentifizierung)
• RFC 5082 für TTL Security Mechanism (GTSM) und sichere eBGP Peerings
• RFC 9293 für TCP-Verhalten (Retransmissions/Timers), relevant bei BGP Flaps
• Wireshark Dokumentation für BGP/TCP-Analyse und Protokollforensik
• tcpdump Manpage für effiziente Captures und Filterpraxis

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.