Zusammenfassung

  • RFC 9786 verlegt die DF-Wahl von einzelnen Ethernet Tags auf den ES-Port, prüft damit aber nicht alle gebündelten Dienste.
  • Port Mode setzt Einstimmigkeit bei Algorithmus und Capability-Bitmap voraus. Eine abweichende PE kann den gesamten ES auf das Standardverfahren zurückfallen lassen.
  • LACP, ARP/ND, MAC, VRF, P/B, FIB, Paketbeobachtung und Kundenabnahme sind eigenständige Beweisobjekte.

Ein Port übernimmt die Verantwortung vieler Dienste

RFC 9786 beschreibt Port-Active als schnittstellenweiten Active/Standby-Modus für EVPN-Multihoming. Anders als die Wahl je [ES, Ethernet Tag] aus dem Umfeld von RFC 7432 lässt das Verfahren den Tag weg. Eine PE hält den Access-Port aktiv, die übrigen halten ihre Ports in Bereitschaft. L2, VPWS, L3 und IRB folgen gemeinsam.

Der CE behält ein einziges LAG; die PEs müssen identische LACP System ID, Port Priority und Port Key präsentieren. Das ergibt einen deterministischen Schnittstellenpfad, etwa für QoS. Der Mechanismus ist unabhängig vom Underlay und schreibt weder ICCP noch LDP vor.

Die Bündelung konzentriert jedoch die Auswirkung. Der DF soll den Access-Port up und forwarding halten. Non-DFs sollen alle VLANs bidirektional blockieren und dürfen den Port down oder LACP Out of Sync halten. Diese Sollzustände werden von der Wahl nicht gemessen. „DF“ benennt den Verantwortlichen, nicht die erfolgreiche Ausführung.

Einstimmigkeit ist nur der Eintritt in das Verfahren

IANA weist in den BGP Extended Communities Bit 5 Port Mode zu. Bei P=1 rechnen Modulo und HRW auf dem ES ohne Ethernet Tag. Die Preference-Verfahren aus RFC 9785 können Ports ordnen; Don’t Preempt kann nach einer Wiederkehr den Amtsinhaber behalten.

RFC 8584 verlangt für den Einsatz die Übereinstimmung aller empfangenen ES Route Type 4 bei Algorithmus und Bitmap. Fehlt die Community, tritt sie mehrfach auf oder weicht eine Anzeige ab, gilt Algorithm 0 ohne Capabilities. RFC 9786 bezeichnet diese Bedingung als Unanimity.

Damit kann eine Änderung an nur einer PE das Wahlregime des gesamten ES verändern. Der RFC nennt unfaire Lastverteilung, Unterbrechung, Verlust und Duplikate als mögliche Folgen. Ein lokales P=1 ist deshalb unzureichend; der Nachweis muss die Anzeigen aller Teilnehmer und ihren Zeitpunkt enthalten.

Auch vollständiger Konsens sagt nichts über Optik, LACP-Partner, collecting/distributing, Adjazenz, VRF oder FIB. Die Wahl ist eine korrekte Berechnung über Kandidaten. Sie ist kein Testpaket für die Datenebene.

Warm Standby deckt nur einen Übergang ab

Ein Standby-Port kann operational down sein und beim Wechsel erst hochfahren. RFC 9786 empfiehlt daher Vorabsynchronisation: ARP- und Neighbor-Discovery-Caches für IRB/L3, möglicherweise VRF-Tabellen sowie MAC-Tabellen für L2. Keine dieser Übertragungen wird durch die DF-Wahl erledigt.

LACP Out of Sync kann den Port als warmen Standby vorbereiten. Das reduziert Link-Anlaufzeit, bescheinigt aber weder aktuelle Nachbarn und MACs noch programmiertes FIB und entfernte Pfade. Umgekehrt beweist replizierter Zustand nicht, dass der CE den Member verwendet.

Primary/Backup deckt die Signalisierung ab. RFC 8214 definiert L2-Attr; RFC 9786 empfiehlt in Ethernet A-D per-ES nur P oder B. Das übergeordnete per-ES P/B soll per-EVI übersteuern. So kann ein Remote-PE schneller umschalten, doch ein empfangenes Bit ist kein beobachtetes Paket.

Ältere RFC-7432/RFC-8214-Implementierungen ignorieren per-ES L2-Attr und nutzen weiterhin die Standardauflösung, während Single-Active über ESI Label sichtbar bleibt. In gemischten Umgebungen können Geräte mit verschiedenen Informationsmengen entscheiden. Capability-Inventar und tatsächliche Empfangsdaten sind daher Teil des Nachweises.

Ein Dienst kann ausfallen, ohne die Portwahl zu ändern

Port Mode schließt AC-DF aus: A muss bei P=1 null sein, ein empfangenes A=1 wird ignoriert. Fällt eine Subschnittstelle aus und wird Ethernet A-D per-EVI zurückgezogen, beeinflusst das die Port-DF-Wahl nicht. Das schützt die aggregierte Entscheidung vor Dienstflattern — und beweist, warum ein stabiler DF keine Dienstgesundheit bescheinigt.

Der Betrieb braucht zwei verknüpfte Ansichten. Die Portansicht enthält ESI, Teilnehmer, Algorithmus, Bitmap, Timer, DF/BDF, LACP und per-ES P/B. Die Dienstansicht enthält VLAN/EVI/VPWS/VRF, ARP/ND, MAC, FIB, Adjazenzen, Zähler, Remote-Reachability und Kundenprobes. Die erste ordnet Kontrolle zu, die zweite prüft Wirkung.

RFC 9722 kann Aktivierungsfenster ausrichten, misst aber keine Applikationszustellung. RFC 9784 behandelt vES, EVC/ENNI-Fehlergrenzen und gruppierte Withdrawals. RFC 9785 behandelt Präferenz. RFC 9786 verwendet Bausteine daraus für die Portaggregation, nicht als Bereitschaftsgarantie.

Der RFC-Editor-Eintrag, der IETF Datatracker und die Errata-Suche belegen den Dokumentstatus. Bei der Erfassung am 11. September 2026 waren keine passenden Errata verzeichnet. Sie belegen keine Implementierung, Nutzung, Konvergenzzeit oder SLA.