Zusammenfassung

  • Highest-Preference und Lowest-Preference aus RFC 9785 ordnen nur bereits geeignete PE-Kandidaten; die Spezifikation setzt deren Betriebsbereitschaft ausdrücklich voraus.
  • Kandidatenstatus, konfigurierte Präferenz, angekündigte In-use-Präferenz, Wahlergebnis, programmierte Weiterleitung und Kundenergebnis sind getrennte Tatsachen.
  • Don't Preempt kann einen zweiten Umschaltvorgang nach der Rückkehr eines bevorzugten PE vermeiden, lässt dafür aber möglicherweise einen administrativ nachrangigen Amtsinhaber im DF-Amt.

Die Zahl entscheidet über die Reihenfolge, nicht über den Zustand

Der Designated Forwarder sendet in einem All-Active-EVPN Broadcast-, Unknown-Unicast- und Multicast-Verkehr zu einem mehrfach angebundenen Gerät oder Netz. Im Single-Active-Betrieb gehört auch Unicast zu seiner Verantwortung. RFC 7432 definiert diese Rolle; RFC 8584 erweitert das Wahlverfahren.

RFC 9785 ergänzt zwei vom Betreiber steuerbare Algorithmen. Algorithmus 2 wählt den höchsten numerischen Preference-Wert, Algorithmus 3 den niedrigsten. Das zwei Oktette lange Feld reicht von 0 bis 65535; ohne Konfiguration gilt 32767. Das IANA-Register führt beide Algorithmen und das D-Bit für Don't Preempt.

Damit lässt sich beispielsweise vor einer Wartung der Rang des aktuellen DF senken. Lokale Richtlinien können die Präferenz auch dynamisch ändern. Doch die normative Voraussetzung bleibt eng: Die Verfahren wählen nach Präferenz, wenn die Kandidaten bereits operationally ready sind. Ein hoher Wert sagt nichts darüber aus, ob der Attachment Circuit funktioniert, die Weiterleitungstabelle installiert ist oder die Gegenstelle tatsächlich Frames empfängt.

Eignung muss vor dem Vergleich feststehen

Eine DF-Wahl beginnt nicht mit dem Zahlenvergleich. Die PEs entdecken einander, führen eine Kandidatenliste und warten die vorgesehene DF_WAIT-Phase ab. Bei aktiviertem AC-DF verlangt RFC 9785 außerdem den Empfang der passenden Ethernet-A-D-per-ES- und per-EVI-Routen, bevor ein PE für das betreffende Segment und Tag als Kandidat gilt.

Das ist ein sinnvoll begrenzter Kontrollnachweis. Er reicht aber nicht bis in die Datenebene. Er sieht weder die tatsächlich programmierte BUM-Replikation noch einen verspäteten Single-Active-Unicast-Pfad. RFC 7432 berücksichtigt sogar Übergangsphasen, in denen zwei PEs sich gleichzeitig für den DF halten können. Split Horizon begrenzt daraus entstehende Schleifen; es bescheinigt keine verlustfreie Umschaltung.

Auch die Algorithmen müssen auf allen PEs übereinstimmen. Kündigt ein Teilnehmer Highest-Preference und ein anderer Lowest-Preference an, fallen alle auf den Standardalgorithmus aus RFC 7432 zurück. Wer später nur „DF = PE2“ speichert, verliert daher die entscheidenden Eingaben: Kandidatenmenge, Algorithmus, Fallback und Tie-Break.

Nicht-revertiv bedeutet eine beabsichtigte Abweichung

Fällt ein bevorzugter PE aus, übernimmt der nächste Kandidat. Kehrt der frühere DF zurück, würde eine sofortige Rückwahl eine weitere Datenebenenänderung auslösen. Don't Preempt bietet deshalb einen nicht-revertiven Ablauf, der den Amtsinhaber zunächst schützt.

Nach einem Boot- oder Hold-Timer wertet der zurückkehrende PE die empfangenen Ethernet-Segment-Routen aus und bestimmt einen Referenz-PE. Würde seine konfigurierte Präferenz den Amtsinhaber verdrängen, kann er dessen operative In-use-Präferenz übernehmen und DP=0 ankündigen. Der amtierende PE kündigt weiterhin DP=1 an und gewinnt bei gleicher Präferenz den Tie-Break.

Konfiguration und Ankündigung widersprechen sich dabei nicht. Die administrative Präferenz hält die langfristige Reihenfolge fest; die In-use-Präferenz bildet den momentan geschützten Zustand ab. Ein Betriebsmodell braucht beide Werte samt DP und Referenz, sonst erscheint ein korrekt nicht-revertiver Zustand als Konfigurationsfehler.

Der Preis ist ebenfalls sichtbar: Ein PE kann DF bleiben, obwohl Kapazität, Standort oder Betriebsrichtlinie inzwischen einen anderen bevorzugen. Ein Routenzug, ein Ausfall des Referenz-PE, eine neue Präferenzänderung oder ein Algorithmuskonflikt verändert die Wahl erneut. Don't Preempt ist deshalb kein allgemeines Sicherheitsmerkmal, sondern eine bewusste Wahl zwischen Umschaltstabilität und Rückkehr zur Sollreihenfolge.

Konfigurationsmacht ist Verkehrsmacht

Der Sicherheitsabschnitt von RFC 9785 formuliert die Folge deutlich: Die Konfiguration erhält absolute Kontrolle darüber, welcher PE für ein Tag gewinnt. Wer diese Konfiguration manipulieren kann, kann die Verkehrsverantwortung umlenken. Ein provozierter Algorithmuskonflikt kann zusätzlich das nicht-revertive Verhalten durch den Fallback aushebeln.

Lokale Überschreibungen pro Ethernet Tag erlauben eine Lastverteilung, müssen aber auf allen PEs gleich sein. Unterschiedliche Sichtweisen können laut Spezifikation Drops oder Duplikate erzeugen. Ein belastbarer Änderungsnachweis verbindet daher Autorisierung, administrative und angekündigte Werte, DP, Algorithmus, Kandidatenstatus, Wahlergebnis, Datenebenenprogrammierung und Verkehrsbeobachtung.

RFC 9784 bestätigt die Anwendung der Präferenzverfahren auf virtuelle Ethernet Segments. Seine Themen – EVC- und ENNI-Fehlerumfang, vESI und gruppierte Withdrawals – bleiben ein eigener Mechanismus. Redundante Multicast-Quellen sind ebenfalls nicht Gegenstand dieser Analyse.

Der RFC-Editor-Datensatz, der IETF Datatracker und die bei der Prüfung leere Errata-Suche belegen den Dokumentstatus, nicht Verbreitung oder Produktionsleistung.