Zusammenfassung

  • BFD prüft schnell die Lebendigkeit eines bestimmten Datenprotokollpfads; die Sitzung bleibt an Endpunkte, Kapselung und Parameter gebunden.
  • Up zeigt nicht, dass alle ECMP-Mitglieder, Adressfamilien, Routen, MTUs oder Dienste denselben gesunden Pfad benutzen.
  • Eine Dienstaussage braucht einen verbundenen Nachweis: BFD-Identität und Timer, RIB/FIB, Mitgliederabdeckung, bidirektionale Tests in Dienstgröße und eine Anwendungstransaktion.

Grün im Dashboard, Schwarzloch im Datenstrom

Stellen Sie sich folgendes Szenario vor: Ein Wartungsfenster endet, alle Routing-Nachbarschaften sind zurück. Das Dashboard meldet BFD Up für den kundenseitigen nächsten Hop, also wird die Änderung geschlossen. Wenige Minuten später stocken große Übertragungen weiterhin. Kleine Kontrollpakete landen auf einem gesunden Bündelmitglied; ein Teil der Produktionsflüsse wird auf ein anderes Mitglied mit fehlerhaftem Forwarding-Eintrag oder falscher MTU-Behandlung verteilt.

BFD hat nichts Falsches behauptet. Der Fehler liegt in der vergrößerten Reichweite der Interpretation. Grün gehört zu einer bestimmten Sitzung und dem von ihren Paketen geprüften Pfad. „Der Dienst ist erreichbar“ ist eine umfassendere Aussage über Routenauswahl, alle relevanten Mitglieder, Hin- und Rückweg, Produktionsgrößen und die Anwendung.

RFC 5880 gibt BFD eine bewusst genaue Aufgabe: Fehler im bidirektionalen Pfad zwischen zwei Forwarding Engines mit geringer Verzögerung erkennen, einschließlich Interfaces, Datenlinks und möglichst der Engines selbst. BFD ist unabhängig von Medium und Routingprotokoll. Das macht es schnell und vielseitig, verlangt aber einen Datensatz darüber, welchen Client und Pfad sein Ergebnis berät.

BFD besitzt keine Discovery. Eine Anwendung fordert die Sitzung an und liefert Adressen und Parameter. Für jeden Kommunikationspfad und jedes Datenprotokoll gibt es eine eigene Sitzung. Physischer Link, virtuelle Verbindung, Tunnel, MPLS-LSP und Multihop-Pfad können BFD tragen; die Aussage von Up bleibt an die jeweilige Kapselung gebunden.

Was Up tatsächlich aufzeichnet

Im asynchronen Modus senden beide Systeme periodisch BFD-Control-Pakete; bleibt genügend Empfang aus, wird Down erklärt. Im Demand-Modus kann der periodische Austausch ruhen, weil eine unabhängige Prüfung vorausgesetzt wird; eine Poll-Sequenz fordert eine ausdrückliche Kontrolle an. Echo lässt Pakete durch den entfernten Forwarding-Pfad zurücklaufen.

Diese Modi liefern nicht denselben Beleg. Echo kann manche Forwarding-Fehler entdecken, die ein reiner Control-Austausch übersieht. Demand hängt von einer unabhängigen Prüfung ab. Eine Implementierung in der Control Engine kann das Schicksal des Routingprozesses teilen; das C-Bit sagt lediglich, ob die entfernte BFD-Implementierung Control-Plane-Unabhängigkeit meldet. Nur Up zu speichern, entfernt den entscheidenden Kontext.

Auch die Timer begrenzen die Aussage. Gewünschtes Sendeintervall, erforderliches Empfangsintervall und Detection Multiplier bestimmen die Erkennungszeit. Up zu einem Zeitpunkt heißt, dass der Zustandsautomat unter diesen Parametern keinen Fehler erklärt hatte. Es verspricht weder die nächste Sekunde noch die vorgesehene Reaktion des Client-Protokolls.

RFC 5881 macht den Umfang für Single-Hop-IPv4 und -IPv6 konkret. Die Sitzung ist an entferntes System, Interface und Protokoll gebunden. IPv4 und IPv6 brauchen auf demselben Link getrennte Sitzungen. Mehrere Sitzungen belegen nur dann Pfadvielfalt, wenn sie wirklich verschiedene Netzwerkpfade durchlaufen.

Das Dokument beschreibt BFD als OAM für Konnektivitäts- und Verbindungsprüfung in netzbasierten Diensten. Es schließt gewöhnliches BFD jedoch als Anwendungs-zu-Anwendungs-Fehlererkennung über das Internet aus. Ein BFD-Paket beim Nachbarn ist keine erfolgreiche DNS-Anfrage, Bestellung oder Dateiübertragung des Nutzers.

Der Client entscheidet über die Folge

RFC 5882 beschreibt BFD als beratend. Routingprotokolle und andere Clients empfangen den Zustand und reagieren mit eigenen Mechanismen. BFD trägt keine anwendungsspezifischen Informationen. Down kann einen Routenrückzug beschleunigen, doch Nachbarschaft, Topologie und Forwarding bleiben Entscheidungen des Clients.

Selbst die Historie kann gefiltert sein. Eine Implementierung darf ein schnelles Up/Down/Up durch Hysterese vor Clients verbergen. AdminDown drückt Verwaltungsabsicht aus, nicht zwingend einen Datenpfadfehler. Aktueller Zustand, Übergänge, Benachrichtigung und tatsächliche Client-Aktion sind daher getrennte Fakten.

ECMP kann BFD und Nutzerflüsse auf verschiedene Mitglieder schicken. Ein kleines Paket passiert, wo Dienstgröße an der MTU scheitert. Der Rückweg kann allein ausfallen, eine Route im RIB ohne gewünschte FIB liegen oder die Anwendung korrekt zugestellten Verkehr ablehnen. Eine grüne Zelle beantwortet diese Fragen nicht.

Quellen