Netzwerk & WAN
BFD
BFD (Bidirectional Forwarding Detection) erkennt Pfadausfälle zwischen zwei Geräten in Bruchteilen einer Sekunde, unabhängig vom verwendeten Routing-Protokoll.
- Ausfallerkennung in Millisekunden
- Protokollunabhängig
- Schnellere Konvergenz
- RFC 5880 ff.
- Hardware-Offload möglich
BFD (Bidirectional Forwarding Detection) ist ein schlankes Protokoll, das ausschließlich eine Frage beantwortet: Funktioniert der Weiterleitungspfad zwischen zwei Geräten noch? Es tut das mit kurzen, regelmäßigen Paketen und unabhängig vom Medium und vom Routing-Protokoll darüber. Damit lässt sich ein Ausfall in Millisekunden erkennen, statt auf die sekundenlangen Hello-Timer der Routing-Protokolle zu warten.
Dieser Artikel erklärt die Betriebsmodi, die Aushandlung der Timer und die Berechnung der Detection Time, den Unterschied zwischen Single-Hop und Multi-Hop, die Anbindung als Kunde an OSPF, IS-IS, BGP und statische Routen, die Sonderfälle micro-BFD und Seamless BFD sowie die Fallstricke aus Hardware-Offload, Authentifizierung und zu aggressiven Timern.
1. Was BFD löst
Ein Routing-Protokoll erkennt den Ausfall eines Nachbarn über ausbleibende Hellos. OSPF etwa braucht dafür standardmäßig Sekunden, BGP mit seiner Hold Time sogar deutlich länger. Auf Strecken, deren Ausfall nicht sofort am Linkstatus sichtbar wird, etwa hinter einem Medienkonverter oder über einen Carrier, vergeht so wertvolle Zeit, in der Verkehr ins Leere läuft.
BFD legt eine eigene, schnelle Sitzung über den Pfad und meldet einen Ausfall an die angeschlossenen Protokolle, die dann sofort umrechnen. Es ersetzt keine Routing-Logik, es beschleunigt nur die Erkennung.
2. Betriebsmodi
BFD kennt drei Arbeitsweisen, von denen in der Praxis vor allem die erste zählt:
- Asynchronous Mode (Standard) beide Seiten senden periodisch BFD-Pakete; bleiben sie aus, gilt der Pfad als ausgefallen.
- Demand Mode nach Aufbau der Sitzung wird das periodische Senden eingestellt und nur bei Bedarf per Poll geprüft. Selten genutzt.
- Echo-Funktion ein System sendet Pakete, die der Gegenüber im Forwarding zurückspiegelt, ohne dass dessen Control Plane beteiligt ist. Prüft gezielt die reine Weiterleitung. Bei Multi-Hop ist Echo verboten.
3. Timer und Detection Time
Drei Werte steuern die Erkennung: das gewünschte Sendeintervall (Desired Min TX), das geforderte Mindest-Empfangsintervall (Required Min RX) und der Detect Multiplier. Aus ihnen ergibt sich die Erkennungszeit:
| Größe | Bedeutung |
|---|---|
| ausgehandeltes Intervall | Maximum aus eigenem TX und dem RX der Gegenstelle |
| Detect Multiplier | Anzahl ausbleibender Pakete bis „Ausfall“ (typisch 3) |
| Detection Time | ausgehandeltes Intervall x Multiplier |
Ein gängiger Software-Wert sind 300 ms bei Multiplier 3, also rund 900 ms. Mit Hardware-Offload sind je nach Plattform einige Millisekunden möglich. Solche Sub-50-ms-Angaben sind Auslegungsziele bestimmter Hardware, kein garantierter Wert für jede Strecke.
4. Single-Hop und Multi-Hop
Direkt verbundene Nachbarn nutzen Single-Hop-BFD (RFC 5881) auf UDP-Port 3784; als Basisschutz gegen Spoofing wird dabei TTL 255 erwartet. Geht die Sitzung über mehrere Hops, etwa bei Multi-Hop-BGP oder über einen Tunnel, kommt Multi-Hop-BFD (RFC 5883) auf UDP-Port 4784 zum Einsatz. Dort ist die Echo-Funktion ausgeschlossen, und kryptographische Authentifizierung ist dringend angeraten, weil der TTL-Schutz entfällt.
5. BFD als Kunde der Routing-Protokolle
BFD hat keine eigene Nachbarsuche. Es wird von einem Routing-Protokoll als Dienst angemeldet (RFC 5882): Das Protokoll richtet die Sitzung ein, BFD meldet Zustandsänderungen zurück. Pro Datenpfad soll nur eine BFD-Sitzung existieren, auch wenn mehrere Protokolle sie nutzen.
- OSPF und IS-IS die Sitzung entsteht über die ohnehin laufende Nachbarsuche; ein BFD-Ausfall setzt den Nachbarn sofort auf down.
- BGP besonders wertvoll für eBGP, dessen Hold Time sonst typischerweise 90 Sekunden beträgt. Läuft bei iBGP schon das IGP mit BFD, sollte man BFD für iBGP nicht zusätzlich aktivieren.
- Statische Routen fällt die BFD-Sitzung aus, wird die statische Route zurückgezogen, sodass ein Backup greift.
6. Sonderfälle: micro-BFD und Seamless BFD
Auf einem LACP-Bündel erkennt BFD den Ausfall einzelner Mitglieder nicht, wenn es nur das logische Interface überwacht. micro-BFD (RFC 7130) legt deshalb je physischem Mitglied eine eigene Sitzung; ein Mitglied wird erst in die Lastverteilung aufgenommen, wenn seine micro-BFD-Sitzung steht. Seamless BFD (RFC 7880) verkürzt den Sitzungsaufbau, indem Knoten feste Discriminatoren veröffentlichen, was in großen MPLS- und Tunnelumgebungen die Zahl gehaltener Sitzungen reduziert.
7. Fallstricke aus der Praxis
BFD ist mächtig, aber empfindlich gegen Fehlkonfiguration:
- Software-BFD hängt an der Control Plane läuft BFD nicht in Hardware, kann ein überlasteter oder neu startender Routing-Prozess Sitzungen fälschlich fallen lassen. Das C-Bit signalisiert Control-Plane-Unabhängigkeit, die es ohne Offload faktisch nicht gibt.
- Zu aggressive Timer auf jitterbehafteten Leitungen oder CPU-belasteten Geräten lösen sehr kurze Intervalle Flapping aus und reißen unnötig BGP- oder OSPF-Sitzungen mit.
- Control Plane Policing BFD-Pakete gehen an die Control Plane und unterliegen dort dem Rate-Limit; bei vielen Sitzungen kann CoPP sie ausbremsen.
- Authentifizierung und Offload auf manchen Plattformen schließen sich Hardware-Offload und BFD-Authentifizierung gegenseitig aus; die Auth-Verfahren (MD5/SHA1) gelten zudem als kryptographisch schwach.
8. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Ein Mechanismus für alle Routing-Protokolle und statische Routen | Software-BFD teilt das Schicksal der Control Plane |
| Sehr schnelle Erkennung, mit Offload im Millisekundenbereich | Zu aggressive Timer erzeugen Flapping-Kaskaden |
| Entkoppelt Linkausfall-Erkennung von den Protokoll-Timern | Auth-Verfahren (MD5/SHA1) sind schwach; teils inkompatibel mit Offload |
| micro-BFD schließt die Lücke auf LAG-Mitgliedern | CoPP kann BFD bei vielen Sitzungen ausbremsen |
| Herstellerneutral standardisiert (IETF) | Spannung mit Graceful Restart: Neustart wirkt wie ein Ausfall |
Häufige Fragen zu BFD
Die Erkennungszeit ist das ausgehandelte Intervall multipliziert mit dem Detect Multiplier. Ein verbreiteter Software-Wert sind 300 ms bei Multiplier 3, also rund 900 ms. Mit Hardware-Offload sind je nach Plattform wenige Millisekunden erreichbar. Sehr kurze Werte sind Auslegungsziele bestimmter Hardware und auf jeder Strecke einzeln zu prüfen.
BFD ersetzt nicht die Routing-Logik, sondern nur die langsame Ausfallerkennung. Die Protokolle melden sich als Kunden bei BFD an und reagieren sofort auf einen gemeldeten Pfadausfall, statt auf ihre eigenen Hello- oder Hold-Timer zu warten. So sinkt die Konvergenzzeit erheblich.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
BFD im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.