Zusammenfassung

  • RFC 9764 vergrößert die Transportnutzlast um ein gültiges BFD-PDU auf einen konfigurierten Wert. Die Füllbytes sind null; bei IPv4 ist Don't Fragment Pflicht. Up belegt damit die wiederholte Ankunft genau dieses großen Kontrollverkehrs.
  • Die Aussage gilt pro Richtung und für die tatsächlich ausgeübte Weiterleitungsbehandlung. Eine bidirektionale Aussage braucht Konfiguration an beiden Enden; LAG oder ECMP können problematische Mitglieder außerhalb des BFD-Flusses lassen.
  • pdu-size ist eine gemeinsame Steuergröße. Der größte Bedarf mehrerer Clients soll maßgeblich sein, sodass eine Erhöhung eine laufende Sitzung zu Down bringen und Reaktionen anderer Clients auslösen kann, bevor Ursache und Reichweite geklärt sind.

Der Wartungsauftrag nannte nur eine Zahl. Ein Netzteam sollte die BFD-Paketgröße erhöhen und prüfen, ob die Sitzung Up blieb. Niemand hatte aufgeschrieben, dass dieselbe Sitzung drei Protokolle bediente oder dass ihr Down-Zustand eine breite Routenänderung auslösen würde.

RFC 9764 macht aus dieser Zahl eine echte Betriebsbedingung. Gewöhnliche BFD-Pakete sind klein. Sie können erfolgreich sein, obwohl größere Anwendungsdatagramme am Path MTU scheitern. Der RFC behält den Asynchronous Mode bei und vergrößert die Transportnutzlast bis bfd.PaddedPduSize.

Die zusätzlichen Bytes müssen null sein; der Empfänger soll ihren Inhalt nicht prüfen. Bei IPv4 muss Don't Fragment gesetzt werden. Ein zu großes Paket kann den Test also nicht durch Fragmentierung in kleinere Einheiten bestehen.

Die gemeinsame Regel bleibt klein. Die Organisation muss verhindern, dass ihre Interpretation größer wird als der Versuch.

Die Sitzung prüft eine Untergrenze, nicht das Maximum

Die Zustandsmaschine stammt weiterhin aus RFC 5880. RFC 9764 führt keinen neuen MTU-Zustand ein. Werden die vergrößerten Kontrollpakete nicht mehr empfangen, folgt BFD seinem normalen Ausfallverfahren.

Up bei 1.512 Byte bedeutet: Die beobachteten BFD-Pakete dieser Größe sind unter der aktuellen Behandlung angekommen. Es bedeutet nicht, dass der Path MTU exakt 1.512 Byte beträgt. Der Pfad könnte mehr tragen. Eine spätere Erhöhung der Kapazität bleibt unsichtbar, weil weiterhin nur die gewählte Untergrenze geprüft wird.

RFC 1191 bindet den Path MTU an einen bestimmten Pfad und lässt den Sender seine Schätzung nach begrenzter Rückmeldung senken. RFC 8899 beschreibt Packetization-Layer-Sondierung für Datagrammtransporte. RFC 9764 sucht keinen Höchstwert. Es hält eine vom Client geforderte Mindestgröße unter Beobachtung.

Darum ist die lokale Interface-MTU kein automatischer Eingabewert. Ein 9.000-Byte-Port kann in einen kleineren Tunnel führen; die Anwendung kann nur 1.400 Byte benötigen. Ein unnötig hoher Wert schafft Verfügbarkeitsrisiko, ein zu niedriger Wert erzeugt eine grüne Sitzung ohne Aussage zum eigentlichen Bedarf.

Zwei Richtungen brauchen zwei Nachweise

„Bidirectional“ im Protokollnamen ersetzt keine Konfiguration der Rückrichtung. Wer die Größe in beiden Richtungen bestätigen will, muss PaddedPduSize an beiden Enden setzen.

A nach B kann andere Router, Tunnel, Queues oder Filter benutzen als B nach A. Manche Netze sind absichtlich asymmetrisch. Dann können auch unterschiedliche Werte richtig sein. Der Nachweis muss Sender, Empfänger, Größe, Zeitpunkt und Konfigurationsepoche je Richtung enthalten.

RFC 5881 behandelt Single-Hop-BFD. Auf einer Direktverbindung liefert die Interface-MTU bereits starke lokale Information. RFC 5883 behandelt Multihop-BFD, wo die erste Schnittstelle die späteren Engstellen nicht beschreibt. Gerade dort ist der große Kontrollverkehr nützlich, aber auch besonders leicht zu überschätzen.

Ein Dashboard darf beide Richtungen zusammenfassen. Ein Prüfpfad darf die beiden zugrunde liegenden Beobachtungen nicht verlieren.

Der größte Client setzt die gemeinsame Schwelle

Mehrere BFD-Clients können dieselben Endpunkte und dieselbe Sitzung nutzen. Fordert einer 1.400 Byte und ein anderer 1.600, soll die Implementierung den größeren Wert wählen. Andernfalls könnte BFD Up sein, obwohl die Anforderung des zweiten Clients nicht erfüllt ist.

Diese Regel verleiht dem größten Antrag gemeinsame Wirkung. Ein neuer Client kann die Bedingungen einer etablierten Sitzung ändern. Verarbeitet der Peer normales BFD, aber keine 1.600-Byte-Transportnutzlast, geht die Sitzung Down; auch Clients mit kleinerem Bedarf können darauf reagieren.

Der Änderungsnachweis muss Antragsteller, abhängige Clients, alten und neuen Wert, Fähigkeiten beider Enden, Down-Aktionen und Rückfallwert nennen. Ohne diese Herkunft wird ein lokaler Bedarf zur unsichtbaren Steuerung anderer Systeme.

Die Änderung ist selbst Teil der Ursache. Sie kann eine bestehende Engstelle sichtbar machen oder erstmals ein Format senden, das der Peer verwirft. „Messung entdeckte Fehler“ und „Änderung erzeugte Inkompatibilität“ dürfen nicht zusammenfallen.

Verschiedene Ursachen erzeugen dieselbe Nichtankunft

Das innere BFD-PDU bleibt unverändert. Trotzdem können Implementierungen große Transportnutzlasten ablehnen oder eine zu strenge Längenprüfung anwenden. Aus Sicht der Zustandsmaschine sieht das genauso aus wie ein Paketverlust an einer MTU-Grenze.

Ein Zwischenfilter kann nach Größe oder Protokoll verwerfen. Ein Angreifer auf dem Pfad kann BFD selektiv fallen lassen und Down erzwingen. Nullfüllung verhindert die Übertragung nicht initialisierter lokaler Daten, bescheinigt aber keine Fehlerursache.

Drei Aussagen gehören in getrennte Felder: „Große Kontrollen hielten die Sitzung nicht aufrecht“ ist Beobachtung. „Der Path MTU liegt unter dem Wert“ ist Diagnose. „Die Route wird entzogen“ ist Entscheidung. Peer-Prüfung, Mitschnitt an beiden Enden, Empfangszähler, Vergleich mit dem alten Wert und Dienst-Canary müssen dazwischenliegen.

ECMP kann den Fehler außerhalb des Kontrollflusses halten

LAG und ECMP verteilen Flüsse auf mehrere Mitglieder, während höhere Schichten einen Pfad sehen. Der BFD-Hash kann ein gesundes Mitglied wählen. Kundenverkehr kann auf einem anderen Mitglied mit kleinerer MTU landen. BFD bleibt Up, während ein Teil des Dienstes ausfällt.

RFC 7130 beschreibt BFD für LAG-Mitglieder. RFC 9764 hält zugleich fest, dass es kein allgemeines standardisiertes Multihop-BFD-Verfahren gibt, das jedes ECMP-Mitglied ausübt. Produkte können internes Wissen nutzen, doch diese Reichweite ist implementierungsspezifisch.

Die korrekte Aussage lautet: Dieser Kontrollfluss bestand den Test auf der tatsächlich gewählten Behandlung. Sie lautet nicht: Jede Entropie und jedes Mitglied wurde geprüft. Unterschiedliche Mitglieds-MTUs machen die Kapazität flussabhängig.

Der bestehende BTW-Bericht zu RFC 9978 trennt gezählte fehlende BFD-Kontrollen von nachgewiesenem Datenebenenverlust. Hier verläuft die Grenze zwischen der Größe des Kontrollflusses und der Größe aller Nutzflüsse.

Das YANG-Blatt ist Absicht, Zustand und möglicher Auslöser

ietf-bfd-large erweitert die BFD-Modelle aus RFC 9314 nach der NMDA-Architektur aus RFC 8342. Es ergänzt das Feature padding und das schreibbare Blatt pdu-size für Single-Hop-, Multihop-, LAG- und MPLS-Strukturen.

Ein Wert im Datastore belegt Konfigurationsabsicht. Er belegt noch nicht den operativen Zustand an beiden Enden oder die Paketzustellung. Version, Peer-Fähigkeit, anfordernde Clients, Aktivierungszeit und Paketbeobachtung gehören zusammen. Der RFC warnt ausdrücklich, dass eine Änderung bei Up die Sitzung zu Down bringen und mehrere Clients treffen kann.

RFC 7880 liefert den S-BFD-Kontext; die große Kapselung kann dort ebenfalls eingesetzt werden. Wiederverwendung vereinheitlicht weder Pfad noch Richtung noch Verantwortlichkeit.

Wiederholung verringert Alter, nicht Unsichtbares

RFC 9869 bestätigt mit REQ/RES-Tokens einen bestimmten UDP-Options-Größenprobe. Der zugehörige BTW-Artikel besitzt die Grenze zwischen bestätigtem Probe-Paket und künftigem Datagramm. RFC 9764 verbessert die Aktualität durch periodische Wiederholung in BFD.

Das nächste Dienstpaket kann trotzdem einen anderen ECMP-Hash, eine andere Kapselung oder Queue erhalten. Wiederholung macht Evidenz frischer; sie macht aus einer Stichprobe keine Gesamtheit.

Ein prüfbarer Satz enthält Zeit und Geltungsbereich: „Unter dieser Konfiguration blieb diese Richtung zuletzt mit X-Byte-BFD Up.“ „Das Netz unterstützt X“ löscht den Beobachter und das Nichtgeprüfte.

Quellen und Evidenzgrenze

Der eingefrorene Satz umfasst RFC 9764, die BFD-Grundlagen RFC 5880, RFC 5881, RFC 5883, RFC 7130 und RFC 7880, die Modelle RFC 9314 und RFC 8342 sowie den Größenkontext RFC 1191, RFC 8899, RFC 9869 und RFC 9978.

Die Governance-Linse stammt aus Heng Lus Minimum Initial Specification, Running-Code Primacy und Reality Layers. Ein gemeinsamer Standard soll eine kleine lokal prüfbare Tatsache liefern; die nächste Entscheidung bleibt beim Betreiber, der ihre Folgen trägt.