Zusammenfassung

  • RFC 9612 ergänzt MPLS LSP Echo um ein BFD Reverse Path TLV. Der Ingress kann damit einen bestimmten Rückwärts-FEC für BFD Control verlangen; ein Ausfall bleibt dennoch eine Beobachtung der gesamten Runde.
  • Rückgabecode 193 und eine aktive BFD-Sitzung können zugleich wahr sein: Der angeforderte Rückweg fehlt, aber lokale Politik erlaubt einen anderen IP-Rückweg.
  • Eine belastbare Kette verbindet Vorwärts-LSP, Rückwärts-FEC, TLV-Antwort, tatsächlichen Pfad, BFD-Ergebnis, Reply-Path-Prüfung, Umleitung, Benachrichtigung und Dienstzustand.

Der Alarm trägt den Namen des Vorwärts-LSP. Das verleitet dazu, denselben Namen als Ursache in das Ticket zu schreiben. Gemessen wurde jedoch eine Runde. Ein Control-Paket ging hinaus und kam nicht rechtzeitig zurück. Ohne weitere Prüfung ist offen, auf welcher Seite die Kontinuität verloren ging.

Der Rückwärts-FEC kann während einer Wartung neu aufgelöst worden sein. Der Egress kann den gewünschten Rückweg nicht mehr finden. Ein IP-Fallback kann an seine Stelle treten. Auch der Vorwärts-LSP kann tatsächlich defekt sein. Der schnelle Detektor ordnet diese Möglichkeiten nicht von selbst.

RFC 9612 ist Experimental. Es erweitert MPLS LSP Echo Requests um das BFD Reverse Path TLV. Darin nennt der Ingress geeignete Target-FEC-Stack-Sub-TLVs, damit der Egress periodische BFD-Control-Pakete über den gewünschten Rückwärts-LSP sendet.

Der Standard setzt eine schmale gemeinsame Grenze. Er definiert Anforderung, Änderung, Rücknahme und präzise Fehler. Die Entscheidung über lokalen Ersatz bleibt beim Egress. Der laufende Datenpfad muss anschließend belegen, was wirklich geschah. Protokollabsicht und Betriebsergebnis sind keine Synonyme.

Detektion misst Zeit, nicht automatisch Richtung

RFC 5880 beschreibt BFD als schnelle Kontinuitätsprüfung. Bei MPLS nach RFC 5884 kann der Hinweg dem LSP folgen und die Antwort über IP-Routing zurückkehren. Das beweist Erreichbarkeit der Endpunkte, nicht die isolierte Gesundheit des Hinwegs.

Das neue TLV hat Typ 16384. Es trägt null oder mehr zulässige, nicht-multicastfähige Target FEC Stack Sub-TLVs. Multicast-FECs führen zu Rückgabecode 192. Standardmäßig werden höchstens 128 Einträge verarbeitet, um aufgeblähte Anforderungen und deren Ressourcenwirkung zu begrenzen.

Ein bestimmter Rückweg verbessert die Versuchsanordnung. Beide Seiten können dokumentieren, was verlangt und angenommen wurde. Fällt BFD aus, bleiben aber Hinweg, Rückweg, FEC-Auflösung und Egress-Entscheidung als mögliche Ursachen. Geschwindigkeit erweitert den Informationsgehalt eines Signals nicht.

Ein automatisch als „Vorwärts-LSP defekt“ etikettierter Alarm verwandelt eine Hypothese in Geschichte. Teams prüfen die falschen Knoten, und Automatisierung verschiebt gesunden Verkehr. Der ehrliche Anfangszustand lautet: BFD-Runde unterbrochen, Richtung noch nicht verifiziert.

Code 193 ist kein Totalausfall

Findet der Egress den angegebenen Rückweg nicht, muss er Code 193 liefern. Der Code besagt nur, dass dieser Rückweg nicht gefunden wurde. Er verbietet keine andere BFD-Sitzung.

Lokale Konfiguration kann einen alternativen Weg, typischerweise IP, zulassen. Dann stehen 193 und BFD Up nebeneinander. Das eine ist die Ablehnung der gemeinsamen Absicht, das andere die Kontinuität einer Ersatzrunde. Wer beide in einem grünen Feld zusammenfasst, verliert den Unterschied zwischen Konformität und Verfügbarkeit.

Auch der Dienst hat einen eigenen Zustand. Ein Fallback kann Kontrollverkehr erhalten und zugleich eine zugesagte physische Trennung aufheben. Eine ausgefallene BFD-Sitzung kann andererseits neben einem bereits umgeleiteten Dienst bestehen. Angeforderter Pfad, tatsächlicher Pfad, BFD und Anwendung brauchen getrennte Nachweise.

Ein leeres Reverse Path TLV zieht die vorherige Wahl zurück und übergibt den Rückweg wieder lokaler Politik. Nach einer Spezifikation führt ein LSP Ping mit BFD Discriminator TLV, aber ohne Reverse Path TLV ebenfalls zurück zur periodischen Sendung nach RFC 5884. Auslassung ist hier eine Zustandsänderung, kein bedeutungsloses Nichts.

Der FEC kann sich nach dem Aufbau ändern

Eine Sitzung friert die Kontrollplane nicht ein. Wartung, Rekonvergenz oder Politik können die Auflösung des Rückwärts-FEC ändern. Daher muss die Implementierung den Rückweg auch nach Sitzungsaufbau ändern können.

Nach einem Fehler prüft der Ingress mit dem Reply Path TLV des LSP Ping, ob der Rückwärts-FEC noch gültig ist. Hat er sich geändert, muss die Sitzung auf einen anderen FEC umgelenkt und ein Operator informiert werden. Prüfen, handeln und Rechenschaft geben sind drei getrennte Schritte.

BFD Control läuft schnell. Die Prüfung von Kontroll- und Datenplane mittels Reply Path erfolgt wesentlich langsamer. In diesem Intervall ist der Fehler bekannt, seine Ursache aber offen. Genau diese Unsicherheit muss das Störungsmodell erhalten.

Geplante Wartung kann einen Rückweg vorab ändern und manche Alarme vermeiden. Sie beseitigt weder spontane Änderungen noch den Taktunterschied. Das realistische Versprechen ist eine begrenzte Zeit bis zur Zuordnung, nicht eine sofortige, immer richtige Ursache.

Lokale Entscheidung verlangt sichtbare Konsequenzen

Der Ingress formuliert einen gemeinsamen FEC-Wunsch. Der Egress behält die Hoheit über Fallback, Grenzwerte und Ressourcen. So kann gemeinsame Technik ohne globale Vereinheitlichung lokaler Betriebsmodelle eingeführt werden.

Ein stiller Fallback wäre jedoch keine saubere Autonomie. Er lässt die Gegenstelle glauben, der spezifizierte Rückweg werde überwacht. Telemetrie muss deshalb Anforderung, Antwort und wirkliche Auswahl zeigen.

Die Grenze von 128 Einträgen bildet denselben Gedanken ab. Sie ist eine voreingestellte Schutzlinie gegen Inflation, kein Kapazitätsziel. Implementierungen dürfen strenger sein. Code 192 macht einen unpassenden Multicast-FEC explizit und verhindert unklare Interpretation.

Experimental ist ebenfalls eine begrenzte Aussage. Es bezeichnet Publikationsstatus und Lernziel, nicht Produktunterstützung, reale Verbreitung oder Standards-Track-Reife. Diese Fragen werden mit Version, Konfiguration, Forwarding und Paketen beantwortet.

Eine Beweiskette statt eines Symbols

Vor dem Vorfall gehören Vorwärts-LSP, verlangter Rückwärts-FEC, gesendetes TLV, Antwort und beobachteter Pfad in das Protokoll. BFD-Zustand und Timer kommen hinzu, ersetzen diese Daten aber nicht.

Nach dem Alarm folgen Reply-Path-Ergebnis, aktuelle FEC-Auflösung, Ersatz-FEC, Zeitpunkt der Umleitung und Benachrichtigung. Abschließend werden Verlust, Latenz und Lieferung am Dienst gemessen. Ein lebender Kontrollkanal ist keine Quittung der Anwendung.

Ein Test übt alle Übergänge. Er installiert einen gültigen Rückweg und erfasst Pakete, ändert den FEC während der Sitzung, verlangt einen nicht vorhandenen Pfad und beobachtet 193 mit und ohne Fallback. Er sendet Multicast-FEC für 192, ein leeres TLV zur Rücknahme, den Discriminator ohne Reverse Path und schließlich mehr Einträge als erlaubt.

API, Kontrollplane, Forwarding und Paketmitschnitt müssen übereinstimmen. Software kann einen neuen FEC melden, während Hardware den alten nutzt. Ein IP-Fallback kann funktionieren, ohne im Managementmodell aufzutauchen. Pfadidentität ist erst bewiesen, wenn die Realitätsschichten zusammenpassen.

Der brauchbare Bericht lautet nicht bloß grün. Er kann festhalten: gewünschter Rückwärts-FEC verschwunden, 193 empfangen, BFD über IP fortgesetzt, Dienst verfügbar, Ersatz-FEC per Reply Path bestätigt, Sitzung umgelenkt, Operator informiert. Jede Aussage ist einzeln prüfbar.

Quellen