Zusammenfassung

  • RFC 9784 gibt jedem virtuellen Ethernet Segment eine eigene vESI-Identität und verlangt getrennte EVC-Überwachung; derselbe Port bedeutet nicht denselben Fehler.
  • Ein einzelner EVC-Ausfall bleibt beim zugehörigen vES oder Service. Erst ein belegter ENNI-Ausfall rechtfertigt den gruppierten Rückzug aller tatsächlich verbundenen vESes.
  • Ein BGP Withdraw ist eine Steueranweisung, kein Beleg für richtige Klassifikation, aktuelle Gruppen, vollzogene DF-Wahl, bereinigte MACs oder wiederhergestellten Kundentraffic.

Ein EVC verliert den Dienst. Das physische Interface ist weiterhin up, benachbarte Kunden senden ungestört. Eine alte Port-Logik löscht trotzdem ihren Zustand und macht aus dem begrenzten Defekt einen gemeinsamen Ausfall.

Hinter RFC 9784 steht genau dieses Autoritätsproblem. Die Spezifikation erweitert Ethernet Segments in EVPN und PBB-EVPN, aber sie entscheidet nicht einfach für mehr Signalisierung. Sie verhindert, dass eine logische Beobachtung allein wegen gemeinsamer Hardware eine physische Eingriffsvollmacht erhält.

Fällt der ENNI selbst aus, kehrt sich die Lage um. Dann verlieren viele vESes tatsächlich denselben Pfad. Tausende Einzelmeldungen können die Konvergenz bremsen, und ein vorbereiteter Gruppennachweis wird sinnvoll. Sicherheit entsteht durch die Trennung, nicht durch die Bevorzugung nur einer Granularität.

Aggregation hebt Identität nicht auf

Das ursprüngliche EVPN-Ethernet-Segment umfasst physische Links zwischen Standort und Provider Edges. RFC 9784 erlaubt EVCs, EVC-Gruppen, Pseudowires oder LSPs als virtuelle Ethernet Segments. Auf einem ENNI können damit Single-Homed-, Single-Active- und All-Active-vESes verschiedener Dienste liegen.

Jedes vES muss eine eigene vESI besitzen. Die Designated-Forwarder-Wahl arbeitet auf (vESI, Ethernet Tag), mit VID beziehungsweise I-SID als Servicekontext. Die Identität begrenzt, welche Redundanzgruppe für welchen Dienst reagieren darf.

Ein physischer gemeinsamer Nenner ist ein mögliches Korrelationssignal. Er ist keine Behauptung, dass jede Störung denselben Ursprung hat. Das logische Inventar bleibt neben der physischen Topologie entscheidend.

Sensor und Eingriff brauchen dieselbe Reichweite

Jeder EVC sollte unabhängig überwacht werden. Fällt einer unter vielen am ENNI aus, muss die DF-Wahl für sein zugeordnetes vES ausgelöst werden. Dafür braucht der Nachweis den Detektor, die Uhrzeit und die damalige Kette von EVC über vESI und Service bis zur Redundanzgruppe.

„Port up“ beweist keinen gesunden EVC. „EVC down“ beweist keinen toten Port. Erst die Zuordnung verleiht der Beobachtung operative Bedeutung.

Ausfall oder Erholung eines EVC in einem Single-Homed- oder All-Active-vES darf andere EVCs nicht beeinflussen. Bei Single-Active bleibt die Wirkung in der betroffenen Service Instance; C-MAC Flushing ist auf deren I-SID und die Adressen des betroffenen multihomed Netzes beschränkt.

Die Verifikation muss folglich auch Unverändertes messen. Gesunde Dienste auf demselben ENNI zeigen, ob der Blast Radius eingehalten wurde.

Portweite MAC-Logik kann den Ausfall erzeugen

In PBB-EVPN kann ein B-MAC viele Dienste eines Ports repräsentieren. Wird das MAC-Mobility-Verfahren für den physischen Abschnitt auf einen einzelnen EVC angewandt, können entfernte PEs C-MACs aller EVCs löschen. Gesunde Dienste verlieren Learning State; die Reparatur erweitert den Schaden.

RFC 9784 nutzt die B-MAC/I-SID Route aus RFC 9541, um die Anweisung auf die Service Instance zu begrenzen. Der Empfänger bereinigt nur C-MACs des genannten B-MAC innerhalb des genannten I-SID. Trägt der EVC mehrere VLANs und I-SIDs, können mehrere Routes nötig sein; bei großer Zahl kann ein B-MAC pro vES mit eigenem Withdraw geeigneter sein.

Die richtige Einheit folgt der realen Abbildung. Ein EVC kann mehrere Broadcast Domains tragen, während ein Port Tausende EVCs bündelt. Namen ersetzen das Inventar nicht.

Der echte Portausfall darf als Menge sprechen

Versagt der ENNI, sind alle zugeordneten vESes betroffen. Route Coloring bereitet eine kompakte Darstellung vor: Ein PE versieht vES-spezifische Routes mit einer Farbe für den physischen Port, standardmäßig dessen MAC in der EVPN Router’s MAC Extended Community aus RFC 9135. Empfänger führen die vES-Menge je Farbe.

Eine Grouping Ethernet A-D per ES Route oder in PBB-EVPN eine Grouping B-MAC Route kann diese Menge vertreten. Ihr priorisierter Rückzug erlaubt anderen PEs, DF-Wahl und Failover für die bekannten Mitglieder zu beginnen. Einzelne vES Withdrawals folgen zur Bereinigung der BGP-Tabellen und sollen dieselbe Wahl nicht erneut auslösen.

Die Farbe ist kein Sensor. Sie belegt eine annoncierte Zuordnung. Die Gruppenroute belegt eine annoncierte Menge. Ihr Rückzug belegt die Aussage des Senders. Keines davon beweist die physische Ursache, identische Mitgliedschaft bei allen Empfängern oder erfolgreichen Datenverkehr.

Die gemeinsame Spezifikation bleibt damit minimal. Jeder PE wertet lokalen Zustand aus, wählt und ändert Forwarding. Das Koordinationszeichen erhält keine Autorität über spätere Wirkungen.

Die Reihenfolge gehört zum Beweis

Gruppen- und Einzelrückzug leisten verschiedene Arbeit. Der erste beschleunigt Reaktion aus vorbereitetem Membership State. Die späteren entfernen konkrete Routes. Ein bloßer Endzustand der BGP-Tabelle zeigt weder frühes Failover noch doppelte Wahl oder einen veralteten Gruppenbezug.

Auch Wiederherstellung besteht aus getrennten Aussagen. Eine Advertisement macht einen Pfad wählbar. Eine DF-Wahl bestimmt eine Rolle. Ein MAC-Update ändert lokale Erreichbarkeit. Erst der beobachtete Datenpfad zeigt, ob Frames ankamen und Nachbardienste unberührt blieben.

Der Betriebsnachweis sollte Detektor und Objekt, EVC–vESI–Service–Farbe, Membership jedes Empfängers, Grund für Einzel- oder Gruppenaktion, BGP-Reihenfolge, DF-Resultat, MAC-Operation, Forwarding und Kundentest getrennt enthalten. „EVPN konvergiert“ ist eine Schlussfolgerung, kein Ersatz für diese Belege.

Geteilte Infrastruktur braucht engere Vollmacht

Virtualisierung legt mehr unabhängige Versprechen auf dasselbe Asset. Je dichter der Port, desto teurer eine falsche physische Schlussfolgerung und desto wichtiger logische Identität.

Running-Code-Primacy trennt die Ebenen: Der RFC belegt Veröffentlichung; Konfiguration belegt Absicht; BGP-Trace belegt Nachrichten; Gerätezustand belegt lokale Aktion; Traffic belegt Dienstwirkung. Keine Ebene darf die Autorität der nächsten ausleihen.

Der Fortschritt von RFC 9784 ist daher nicht bloß schnellere Konvergenz. Geschwindigkeit wird an den belegten Umfang gebunden. Ein Circuit-Ausfall bleibt begrenzt. Ein echter Portausfall darf gruppiert werden. Der Gruppenwithdraw bleibt dennoch etwas anderes als ein Wiederherstellungsbeweis.

Quellen

  1. RFC 9784 — Virtual Ethernet Segments für EVPN und PBB-EVPN
  2. RFC 7432 — BGP MPLS-Based Ethernet VPN
  3. RFC 7623 — Provider Backbone Bridging mit EVPN
  4. RFC 8214 — VPWS-Unterstützung in EVPN
  5. RFC 8584 — Erweiterbare EVPN-DF-Wahl
  6. RFC 7023 — Ethernet Connectivity Fault Management
  7. RFC 9135 — Integrated Routing and Bridging in EVPN
  8. RFC 9541 — B-MAC- und B-MAC/I-SID-Routes für PBB-EVPN
  9. Lu Heng — Running-Code-Primacy
  10. Lu Heng — Minimale Anfangsspezifikation und lokale Zukunftsentscheidung
  11. Lu Heng — Realitätsebenen, symbolische Macht und Klarheit