Site icon bintorosoft.com

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

Red Snapper

close-up of a rack of servers with blinking lights and cables, created with generative ai

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.

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.

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

Evidence für TCP-Probleme

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

Praxisregeln für sichere Auth-Baselines

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

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

Stabile Timer-Baseline

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

Max-Prefix und Limits richtig interpretieren

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

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.

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.

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.

Runbook-Baustein: BGP Session Troubleshooting in 15 Minuten

Weiterführende Quellen für Standards und vertiefende Referenzen

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