Site icon bintorosoft.com

BGP-Session-Drop: Hold Timer, Policy oder Transport?

Red Snapper

Audio snake and stage box with xlr cables and jacks at a live show.

Ein BGP-Session-Drop ist für NOC- und On-Call-Teams eines der teuersten Fehlerbilder, weil er selten „nur“ ein Routing-Problem ist. Wenn eine BGP-Session (eBGP oder iBGP) flappt, brechen Routen weg, Rekonvergenz startet, Traffic verschiebt sich, und je nach Topologie entstehen Blackholes, Hot-Potato-Effekte oder unerwartete Pfade. In der Praxis stellen sich nach einem Drop immer dieselben drei Fragen: War es der Hold Timer (Keepalives kamen nicht rechtzeitig), war es Policy (Konfiguration, Auth, Capabilities, Max-Prefix, Route-Map), oder war es der Transport (TCP, MTU, Verlust, Congestion, Firewall/NAT)? Genau diese Unterscheidung entscheidet, ob Sie zuerst auf der Leitung suchen, im BGP-Stack, oder in Change- und Policy-Prozessen. Dieser Artikel liefert ein praxistaugliches Vorgehen, um BGP-Session-Drops eindeutig zu klassifizieren: Welche Signale im Log wirklich zählen, wie Sie Hold-Timer- und Keepalive-Fehler von Transport-Problemen abgrenzen, welche Policy-Fallen typisch sind, und welche Datenpunkte ein gutes Ticket enthalten muss, damit die Eskalation an Backbone-, Security- oder Plattformteams ohne Rückfragen funktioniert.

Was „BGP-Session-Drop“ technisch bedeutet

BGP läuft über TCP (Port 179). Eine Session ist daher nicht nur „BGP up/down“, sondern auch ein TCP-Zustand: Handshake, Datenübertragung, Retransmits, Session-Reset. Ein Drop kann entstehen, weil TCP abbricht (RST, Timeout, NAT-State), weil BGP den Nachbarn aktiv schließt (Notification), oder weil der Hold Timer ausläuft, weil keine gültigen Keepalives/Updates mehr empfangen wurden. Für die operative Diagnose ist entscheidend: Ein BGP-Down ist meistens das Ergebnis eines zuvor liegenden Problems – nicht dessen Ursache.

Die maßgeblichen Grundlagen sind in RFC 4271 (BGP-4) beschrieben. Da BGP über TCP läuft, ist auch RFC 9293 (TCP) als Referenz hilfreich.

Die drei Hauptkategorien schnell trennen: Hold Timer, Policy oder Transport

In einem Incident zählt Geschwindigkeit, aber ohne vorschnelle Schlüsse. Eine robuste Triage nutzt zuerst die „harten“ Indikatoren: Welche Down-Reason steht im BGP-Log? Gibt es eine Notification? Gibt es TCP-Reset/Timeout? Und: Tritt das Problem zeitgleich auf beiden Seiten auf oder nur auf einer? Daraus entsteht eine klare Priorisierung.

Hold Timer verstehen: Was genau läuft ab?

BGP setzt zwei Timer: Keepalive (typisch alle 1/3 des Hold Timers) und Hold (maximale Zeit ohne gültige BGP-Nachricht). Wichtig: Nicht nur Keepalives „füttern“ den Hold Timer, sondern auch andere gültige BGP-Nachrichten (z. B. Updates). Wenn also Updates/Keepalives verspätet sind oder verloren gehen, kann der Hold Timer auslaufen. In stark ausgelasteten Netzen passiert das eher durch Queueing und Controlplane-Drops als durch „Routingfehler“.

Faustregel Keepalive/Hold (MathML)

KeepaliveInterval ≈ HoldTime 3

Hold Timer Expired: Root-Cause-Matrix fürs NOC

Wenn die Down-Reason „Hold Timer Expired“ lautet, ist der häufigste Fehler, sofort am BGP-Timer zu drehen. Das kann kurzfristig stabilisieren, aber es maskiert die eigentliche Ursache. Besser ist eine Matrix aus Symptomen und Schnellchecks.

Symptom: Session flappt unter Last, nachts stabil

Symptom: Hold Timer Expired nur in eine Richtung sichtbar

Symptom: Viele BGP-Sessions gleichzeitig Hold-Timer-Down auf einem Router

Transport-Probleme: Wenn TCP die eigentliche Ursache ist

Da BGP über TCP läuft, sind viele Drops eigentlich TCP-Symptome: Verbindungen werden resettet, Timeouts laufen, MSS/MTU passt nicht, oder Stateful Middleboxes entscheiden, dass die Session „alt“ ist. Der wichtigste praktische Punkt: Ping beweist hier fast nichts. Eine stabile ICMP-Erreichbarkeit kann gleichzeitig mit instabilen TCP-Sessions existieren, insbesondere bei Policy- oder State-Problemen.

MTU/MSS als klassischer „funktioniert manchmal“-Faktor

Ein unterschätzter Sonderfall ist ein MTU-/MSS-Thema: Der TCP-Handshake kann funktionieren, kleine BGP-Nachrichten auch, aber größere Updates (z. B. nach Rekonvergenz) triggern Fragmentierung oder PMTUD. Wenn ICMP „Fragmentation Needed“ geblockt wird, entstehen Blackholes auf Paketgrößenbasis. Das äußert sich dann als scheinbar zufällige Session-Drops, oft korreliert mit Routing-Events. Für PMTUD ist RFC 1191 eine gute Referenz.

EffektiveMTU = LinkMTU – TunnelOverhead

Policy-Probleme: Wenn BGP absichtlich beendet wird

Policy-bedingte Drops sind operativ dankbar, weil sie häufig eindeutige Logs/Notifications erzeugen – aber nur, wenn Logging sauber konfiguriert ist. Typische Policy-Ursachen sind Authentifizierung, Capabilities/Negotiation, Max-Prefix-Schutz, Administrativ-Down oder unerwartete Konfigurationsdrifts (z. B. Peer-IP geändert). Auch interop-spezifische Themen können auftreten, etwa bei Features wie Graceful Restart oder bei 4-Byte-ASNs (je nach Umgebung).

Die Notification-Gründe und Zustandslogik sind in RFC 4271 definiert. Für Graceful Restart ist RFC 4724 eine gängige Referenz.

Praktischer Decision Tree: So entscheiden Sie in der Triage richtig

Im NOC braucht es eine klare Reihenfolge, die in heterogenen Netzen funktioniert. Die folgenden Schritte sind bewusst herstellerneutral formuliert und priorisieren die schnellsten, stärksten Signale.

Schnellchecks, die fast immer helfen

Unabhängig von Vendor und Topologie gibt es ein Set an Checks, das in nahezu jedem Incident Mehrwert liefert. Entscheidend ist, die Ergebnisse so zu notieren, dass sie beweisbar und eskalierbar sind.

Dokumentationsstandard im Ticket: Was ein gutes „BGP-Session-Drop“-Ticket enthält

Bei BGP ist „Beweisführung“ besonders wichtig, weil unterschiedliche Teams beteiligt sein können: Transport/Backbone, Security/Firewall, Plattform/Edge. Ein gutes Ticket spart Eskalationszeit, weil es die Ursache bereits in die richtige Kategorie lenkt.

Typische Fehlerbilder und die wahrscheinlichste Kategorie

Die folgenden Muster helfen, schnell eine Hypothese zu bilden, ohne sich in Details zu verlieren. Wichtig ist: Hypothese bedeutet „erste Richtung“, nicht „Enddiagnose“.

Prävention: Wie Sie BGP-Session-Drops operativ seltener machen

Stabilität entsteht weniger durch „höhere Timer“ und mehr durch konsistente Betriebsmuster: klare Trust-Boundaries für TCP/179, kontrollierte Changes, und Monitoring, das Hold-Timer- und Transport-Symptome früh erkennt.

Outbound-Links für Standards und Vertiefung

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