Entwicklung robuster BGP-Fehlererkennung: Hold-Timer vs. BFD

Die schnelle Fehlererkennung in BGP bedeutet nicht, den niedrigstmöglichen Timer zu wählen. Es geht darum, eine vorhersehbare Konvergenz zu erreichen, ohne die Steuerungsebene zu destabilisieren.

Bei ISP-Backbones, Enterprise-WAN-Cores und EVPN-Rechenzentrums-Fabrics besteht die eigentliche Designfrage darin, ob man die BGP-Keepalive- und Hold-Timer aggressiv anpassen oder BFD für die Erkennung im Subsekundenbereich einsetzen soll.

Die kurze Antwort ist einfach: BGP-Timer sind stabil, aber langsam. BFD ist schnell, muss aber sorgfältig konfiguriert werden.

• Teil 1: Warum BGP Hold Time und BFD wichtig sind
• Teil 2: Unterschiede bei der Implementierung durch die Anbieter
• Teil 3: Sichere Designmuster
• Teil 4: Den Kern schützen
• Teil 5: Vorlagen und Migrationsstrategie

Teil 1: Warum BGP Hold Time und BFD in ISP- und großen Unternehmensnetzwerken wichtig sind

Das Standardverhalten von BGP ist von Grund auf konservativ.

Die Basisspezifikation des Border Gateway Protocol (RFC 4271) sieht eine Keepalive-Zeit von 30 Sekunden und eine Hold-Zeit von 90 Sekunden vor. Viele Plattformen verwenden standardmäßig 60 Sekunden für die Keepalive-Zeit und 180 Sekunden für die Hold-Zeit.

Das bedeutet, dass ein ausgefallener Peer möglicherweise erst nach bis zu drei Minuten als nicht erreichbar gemeldet wird. In modernen MPLS-Kernnetzen, EVPN-Fabrics und WAN-Umgebungen von Unternehmen ist diese Verzögerung betrieblich nicht akzeptabel.

Erkennung zwischen Protokollschicht und Weiterleitungsschicht

BGP-Hold-Timer arbeiten in der Steuerungsebene. Sie hängen vom Zustand der TCP-Sitzung und der CPU-Auslastung ab. Sie wurden nicht für eine Konvergenz im Subsekundenbereich entwickelt.

Die bidirektionale Weiterleitungserkennung (BFD) ist ein ressourcenschonendes Protokoll zur Erkennung von Pfadausfällen. Auf vielen Plattformen kann BFD in Hardware anstatt vollständig in der Steuerungsebene verarbeitet werden, was eine schnellere Erkennung bei geringerer CPU-Auslastung ermöglicht.

Der architektonische Unterschied wird in groß angelegten oder latenzempfindlichen Umgebungen entscheidend.

Teil 2: Wie große Anbieter BGP-Timer implementieren

Zeitverhandlungsverhalten

Die ausgehandelte BGP-Haltezeit entspricht dem niedrigeren der beiden von den Peers vorgeschlagenen Werte. Schlägt eine Seite 180 Sekunden und die andere 30 Sekunden vor, beträgt die Haltezeit der Sitzung typischerweise 30 Sekunden.

Dies bedeutet, dass externe Partner unbeabsichtigt aggressive Zeitvorgaben setzen können, wenn keine entsprechenden Richtlinienkontrollen angewendet werden.

BFD-Integrationsunterschiede

Die Implementierungen der verschiedenen Anbieter unterscheiden sich darin, wie BFD in BGP integriert wird:

• Bindung pro Schnittstelle vs. Bindung pro Nachbar
• Hardwaregestützte vs. CPU-basierte Verarbeitung
• Maximal unterstützte BFD-Sitzungen
• Verhalten während eines Ausfalls der Steuerungsebene

Einige High-End-Plattformen lagern BFD auf Linecards aus, während günstigere Router BFD vollständig in der Steuerungsebene verarbeiten. Skalierungsgrenzen und Mindestintervalle hängen vom Modell und der Softwareversion ab.

Vor der Einführung aggressiver Erkennungsintervalle sollten Sie stets die Hardwarekapazität und die Skalierbarkeit der Sitzungen überprüfen.

Teil 3: Sichere Designmuster

Die Risiken aggressiver BGP-Timer

Die Konfiguration extrem niedriger Timer, wie z. B. 1 Sekunde Keepalive und 3 Sekunden Hold-Zeit, ist ein häufiges Anti-Pattern in der Produktion.

Beispielhafter CLI-Befehl zum Konfigurieren aggressiver BGP-Timer:

router bgp 65000
 timers bgp 1 3

Zu den Risiken gehören CPU-Spitzen, Fehlalarme, Sitzungsinstabilität und übermäßige Routing-Aktivität bei Überlastung.

Internet Edge Peering

Ein sichererer Ansatz ist die Verwendung konservativer BGP-Timer wie 30/90 und optional der Einsatz von BFD mit moderaten Erkennungsintervallen, zum Beispiel 500 ms multipliziert mit 3.

Die Stabilität am Rand des Internets ist oft wichtiger als die theoretische Geschwindigkeit.

MPLS oder ISP-Kern

In Carrier-Cores wird BFD häufig eingesetzt. Beispiele hierfür sind 50-ms-Intervalle mit einem Multiplikator von 3 in sauberen Punkt-zu-Punkt-Glasfaserverbindungen oder 300–500-ms-Intervalle in Metro- und Cloud-Verbindungsumgebungen.

Extrem niedrige Intervalle in Pfaden mit hoher Latenz können zu Instabilität führen.

Data Center EVPN oder iBGP

Bei Blattdorngeweben wird BFD häufig zur schnellen Erkennung eingesetzt. Die Konvergenz kann jedoch auch von der IGP-Next-Hop-Verfolgung abhängen. Eine Verbesserung der IGP-Konvergenz kann stabilere Ergebnisse liefern als eine einfache Verringerung der BFD-Intervalle.

Umgebungen mit hoher Latenz oder IPsec-Umgebungen

Bei BGP over IPsec oder WAN-Verbindungen mit hoher Latenz bieten konservative BFD-Werte wie 1000 ms Sende- und Empfangszeit mit einem Multiplikator von 3–5 oft eine bessere Stabilität als aggressive Einstellungen im Subsekundenbereich.

Teil 4: Den Kern schützen

Verhinderung des Timer-Hijackings

Da bei Verhandlungen die kürzere Haltezeit den Ausschlag gibt, können Edge-Peers unbeabsichtigt aggressive Timer festlegen.

Es empfiehlt sich, Mindestwartezeiten durchzusetzen und Sitzungen abzulehnen, die diese Grenzwerte unterschreiten. Die genaue Umsetzung hängt vom Anbieter und der Version ab.

Ausrichtung des Schutzes der Steuerungsebene

Die Fehlererkennung muss mit den Richtlinien zur Steuerungsebenenüberwachung abgestimmt sein. Werden BGP- oder BFD-Pakete zu stark gedrosselt, können künstliche Fehler auftreten.

Bei der Auslegung sollten die Dimensionierung der Steuerungsebenen-Warteschlange, die DDoS-Sicherheit und die CPU-Kapazitätsplanung berücksichtigt werden.

BFD und Graceful Restart

BFD ist darauf ausgelegt, Fehler sofort zu erkennen und Sitzungen schnell zu beenden. Graceful Restart zielt darauf ab, die Weiterleitung während temporärer Neustarts der Steuerungsebene aufrechtzuerhalten.

Die Kombination beider Ansätze ohne Kenntnis des Plattformverhaltens kann zu Konflikten führen. Verwenden Sie BFD, wenn alternative Pfade vorhanden sind und ein schnelles Failover erforderlich ist. Verwenden Sie Graceful Restart, wenn die Aufrechterhaltung der Weiterleitung während eines Softwareneustarts Priorität hat.

Teil 5: Empfohlene Vorlagen und Migrationsstrategie

Konservative Basislinie

Bei vielen WAN- und Internet-Edge-Bereitstellungen in Unternehmen gewährleisten eine Keepalive-Zeit von 30 Sekunden und eine Haltezeit von 90 Sekunden ein stabiles und interoperables Verhalten.

BFD-fähige Bereitstellung

Wenn eine Erkennung im Subsekundenbereich erforderlich ist, aktivieren Sie BFD pro Nachbar und beginnen Sie mit moderaten Intervallen. Überwachen Sie die CPU-Auslastung und die Sitzungsstabilität, bevor Sie die Erkennungsintervalle verringern.

Migrationsstrategie

Ein sicherer Einführungsansatz umfasst die Validierung der Hardware-BFD-Skalierung, die Aktivierung von BFD auf einer Teilmenge der Peers, die Überwachung der Auswirkungen und die schrittweise Erweiterung.

Überlegungen zur Hardwarekapazität

Nicht alle Routing-Plattformen unterstützen großflächige hardwaregestützte BFD. Vor dem Einsatz einer aggressiven Erkennung sollten Sie die Hardware-Revision, den Lebenszyklusstatus und die maximal unterstützte Sitzungsgröße überprüfen.

Bei Aktualisierungsprojekten mit mehreren Anbietern validieren Ingenieure häufig die Plattformfunktionen, bevor sie eine standardisierte Erkennungsstrategie festlegen. Bei der Beschaffung von Routing-Hardware für Unternehmen müssen die Plattformen eine stabile BFD-Skalierung und ein vorhersehbares Verhalten der Steuerungsebene unterstützen. Anbieter wie beispielsweise Router-Switch Der Fokus sollte auf originaler Enterprise-Netzwerkhardware mit transparentem Lebenszyklus liegen, was die Hardwarevalidierung erleichtert. Die endgültige Auswahl sollte stets auf dokumentierten Plattformspezifikationen und Labortests basieren.

Teil 6: FAQ

Frage 1: Reicht eine Verkürzung der BGP-Haltezeit für eine schnelle Konvergenz aus?

Eine Verkürzung der BGP-Haltezeit kann die Erkennungsgeschwindigkeit verbessern, erhöht aber die Last der Steuerungsebene und das Risiko von Fehlalarmen erheblich. Für die Erkennung im Subsekundenbereich ist die Verwendung von BFD im Allgemeinen sicherer.

Frage 2: Sollte BFD auf allen BGP-Peers aktiviert sein?

Dies hängt von der Hardwarekapazität, der Sitzungsgröße und dem Latenzprofil ab. Prüfen Sie die Plattformgrenzen, bevor Sie BFD flächendeckend aktivieren.

Q3. Können BFD und Graceful Restart zusammen verwendet werden?

Sie dienen gegensätzlichen Zielen. Ihre Kombination erfordert eine sorgfältige plattformspezifische Validierung, um ein unbeabsichtigtes Routen-Flushing während Steuerungsebenenereignissen zu vermeiden.