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

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.

• Transport-bedingt: TCP verliert die Verbindung, Pakete gehen verloren, MTU/PMTUD bricht, Firewall/NAT beendet States.
• Timer-bedingt: Keepalives/Updates kommen zu spät, Hold Timer läuft ab (oft durch Congestion oder CPU/Controlplane).
• Policy-bedingt: BGP sendet/empfängt Notifications wegen Konfigurations- oder Sicherheitsregeln (Auth, Capabilities, Max-Prefix, Admin Shutdown).

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 Expired: häufig Congestion, CPU/Controlplane, Paketverlust oder Filter – weniger häufig „BGP selbst“.
• Notification Received/Sent: häufig Policy/Config (Auth, Capabilities, Cease, Max-Prefix), manchmal auch Software-/Interop-Probleme.
• TCP Connection Reset/Timeout: häufig Transport (Firewall/NAT/State), MTU, asymmetrische Pfade, Link-Instabilität.

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)

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

• Implikation: Wenn der Hold Timer 90 s ist, sind Keepalives oft 30 s. Schon wenige aufeinanderfolgende verlorene oder stark verzögerte Pakete können kritisch werden.
• Praxis: Ein „Hold Timer Expired“ ist häufig ein Symptom für Delay/Loss – nicht zwingend für eine falsche BGP-Konfiguration.

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

• Wahrscheinlich: Congestion auf Links/Queues, Controlplane-Policing (CoPP), CPU-Spikes auf Routing-Prozess.
• Schnellchecks:
  • Interface-Discards/Queue-Drops auf Pfadinterfaces prüfen.
  • Controlplane-Stats: Drops für TCP/179 oder generell für Routing-Protokolle.
  • CPU/Memory/Process-Queues auf beiden Peers vergleichen.

Symptom: Hold Timer Expired nur in eine Richtung sichtbar

• Wahrscheinlich: asymmetrisches Routing, einseitige Filter, unidirektionales Loss, NAT/Firewall-State auf nur einer Richtung.
• Schnellchecks:
  • Pfad-Asymmetrie prüfen (Traceroute/TCP-Path, Routing-Table Next Hop).
  • Firewall/ACL Hits für TCP/179 in beiden Richtungen prüfen.
  • Packet Capture/Telemetry: kommen Keepalives beim Empfänger an?

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

• Wahrscheinlich: lokales Controlplane-Problem, Software-Bug, Ressourcenengpass, Routing-Table-Churn.
• Schnellchecks:
  • Alle betroffenen Nachbarn: gleicher Linecard/VRF/Interface-Pfad?
  • Logs auf „process restart“, „watchdog“, „high CPU“.
  • Routenflap-/Update-Sturm (z. B. nach Link-Event) als Auslöser?

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.

• TCP RST: häufig Firewall, Session-Interception, Security-Zonenwechsel, aggressive Idle-Timeouts.
• TCP Timeout: Paketverlust, MTU/PMTUD-Blackhole, Congestion, asymmetrische Pfade.
• Port 179 gefiltert: ICMP geht, aber TCP/179 wird (teilweise) gedroppt oder gerate-limited.

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.

$\mathrm{EffektiveMTU}=\mathrm{LinkMTU}–\mathrm{TunnelOverhead}$

• Indikator: Drops häufen sich bei großen Update-Bursts (nach Link-Flap, Policy-Änderung, Routen-Recompute).
• Check: MSS-Clamping/MTU-Consistency in Tunnelpfaden und über Middleboxes.

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).

• Authentication Failure: MD5/TCP-AO oder Key-Rotation nicht synchron; Session kommt hoch und fällt sofort wieder.
• Max-Prefix Exceeded: Schutzmechanismus greift, wenn der Peer „zu viele“ Routen sendet (z. B. Leak).
• Cease Notifications: „Administrative Shutdown“, „Peer De-configured“, „Other Configuration Change“.
• Capability Mismatch: selten, aber relevant bei Feature-Rollouts oder gemischten Softwareständen.

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.

• 1) Down-Reason sammeln: „Hold Timer Expired“, „Notification“, „TCP reset/timeout“, „Admin down“. Wenn Sie nur „Idle“ sehen, prüfen Sie zuerst den TCP-Aufbau (Port 179).
• 2) Ist es synchron? Flappt die Session auf beiden Peers zur selben Zeit? Synchron deutet auf Transport/Link/Policy-Change, asynchron eher auf einseitige Filter/Controlplane.
• 3) Ist es korreliert? Zeitgleich mit Link-Events, CoPP-Änderung, Firewall-Change, Route-Policy-Deploy?
• 4) Scope prüfen: Eine Session vs. viele Sessions auf einem Router. Viele Sessions gleichzeitig: Controlplane/Box/Transport-Shared-Domain.
• 5) Payload-Phase testen: Wenn die Session hochkommt, aber bei Updates fällt, ist MTU/PMTUD/Queueing wahrscheinlicher als Auth.

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.

• TCP/179 Reachability: Ist der TCP-Handshake stabil? Gibt es Resets? Timeouts?
• Keepalive/Update-Interval: Kommen BGP-Nachrichten im erwarteten Takt?
• Interface-Health: Errors/Discards, Flaps, DOM/DDM bei Optik.
• Controlplane Drops: CoPP/Policing, CPU-Spikes, Prozess-Queues.
• Policy/Notification Logs: Max-Prefix, Auth fail, Cease reason, Config change.
• Pfad-Asymmetrie: Routing-Table/ECMP, Firewall-Zonen, NAT-Stateful Pfade.

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.

• Peer-Details: Local/Remote IP, ASNs, Session-Typ (eBGP/iBGP), VRF/Instance, Interface/Path.
• Zeitlinie: erster Drop, Flap-Frequenz, Dauer der Down-Phasen, korrelierende Events.
• Down-Reason: exakte Reason/Notification (wenn vorhanden), inklusive Code/Subcode.
• Timer: konfigurierte Hold-/Keepalive-Werte (beide Seiten, wenn verfügbar).
• Transport-Symptome: TCP reset/timeout, Packet Loss Indikatoren, MTU/MSS Hinweise.
• Policy-Symptome: Max-Prefix Trigger, Auth-Fehler, administrative Shutdowns, Change-IDs.
• Impact: betroffene Prefixe/Services, ob es zu Blackholes oder Pfadwechseln kam.

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“.

• „Hold Timer Expired“ nach Traffic-Peak: meist Transport/Queueing/Controlplane, selten Policy.
• Session fällt exakt nach X Minuten Idle: häufig Firewall/NAT Idle-Timeout (Transport/Policy-Middlebox).
• Session kommt hoch und fällt sofort wieder: häufig Auth/Capabilities/Policy oder Port 179 nur teilweise erlaubt.
• Nur ein Peer betroffen, andere Sessions stabil: eher spezifischer Pfad/ACL/MTU oder Peer-seitiges CPU/Interface-Problem.
• Viele Peers fallen gleichzeitig: gemeinsame Fault Domain (Linecard, CoPP, Upstream-Link, Wartung, Controlplane-Kollaps).

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.

• Monitoring auf BGP-Events: Drop-Gründe, Flap-Rate, Keepalive-Jitter, Update-Bursts.
• CoPP/Controlplane-Design: Routing-Protokolle priorisieren, Drops sichtbar machen.
• Max-Prefix mit Alerting: Schutz ja, aber mit sinnvollen Schwellen und Voralarm, um unnötige Session-Kills zu vermeiden.
• Change-Guardrails: Timer/Auth/Policy-Änderungen als „paired change“ auf beiden Seiten, mit Post-Checks.
• MTU/MSS Governance: insbesondere bei Tunneln/Overlays und entlang von Firewall-/NAT-Pfaden.

Outbound-Links für Standards und Vertiefung

• RFC 4271 (BGP-4) für Zustände, Timer-Logik und Notifications.
• RFC 9293 (TCP) für TCP-Verhalten, Retransmits und Session-Stabilität.
• RFC 4724 (Graceful Restart) für kontrollierte Rekonvergenz und Failure Modes bei Restart-Szenarien.
• RFC 1191 (Path MTU Discovery) für MTU/PMTUD-Blackholes, die BGP-Datenübertragung beeinflussen können.

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.