Zusammenfassung

  • RFC 9625 führt eine Supplementary Broadcast Domain ohne Attachment Circuits ein, damit Interesse aus einer normalen BD auch PEs derselben Tenant Domain erreicht, die diese BD nicht führen.
  • Ein PE kann IGMP/MLD-Zustand mehrerer BDs zu SBD-SMET zusammenführen; ein AC ohne Snooping oder ein PE ohne RFC-9251-Support gilt gegebenenfalls als an allen Flows interessiert.
  • Belastbare Evidenz trennt Host-Report, Policy, BD/SBD-Abbildung, Aggregation, Import, Gateway-Wahl, OIF-Eignung pro Frame, Übertragung, Duplikate und Empfang.

Die Route war korrekt, die Reichweite ungeklärt

Auf jedem beteiligten PE ließ sich die SMET-Route erklären. RTs und Tag IDs passten, der Import war erwartbar, und dennoch konnte niemand aus dem installierten Zustand ablesen, wer die tenantweite Wirkung genehmigt hatte. Der Ursprung war ein einzelner IGMP-Report auf einem gewöhnlichen Access-Port.

OISM muss diesen lokalen Hinweis verbreiten. Quellen und Empfänger liegen in verschiedenen Subnetzen; ein entferntes Ingress-PE braucht das Interesse, obwohl es keine normale BD mit dem Empfänger-PE teilt. Die SBD stellt die gemeinsame Fläche bereit und vermeidet unnötiges Hairpinning.

Eine technisch erforderliche Reichweite ist aber keine Autoritätsaussage. Der Report belegt Empfang und Interpretation einer Nachricht. Identität, Group/Source-Regel, Rate, Zustandsbudget und Gültigkeitsdauer entscheiden erst, ob daraus gemeinsamer Aufwand werden darf.

Die SBD besitzt keine ACs und trägt dennoch die Projektion

Alle OISM-PEs einer Tenant Domain werden mit derselben SBD und ihrem SBD-RT versehen. Die SBD hat keine Attachment Circuits. Sie ist kein Kunden-LAN, sondern repräsentiert Quellen und Empfänger, deren tatsächliche BD auf einem entfernten PE nicht vorhanden ist.

Fehlt dem empfangenden PE die echte Source-BD, kann die SBD als apparent source BD dienen. Das hält die Weiterleitung möglich, entfernt aber lokale Herkunft aus der unmittelbaren Sicht. Ein Log mit nur der SBD kann Port, gewöhnliche BD, EVI und Ethernet Segment des Auslösers nicht rekonstruieren.

Darum gehören reale BD und projizierte SBD in denselben Beleg, ergänzt um Tenant Domain und Konfigurationsepoche. Die SBD erklärt den Transport des Kontexts, nicht die Berechtigung seines Ursprungs.

Treat-as-withdraw begrenzt fehlerhafte Klassifikation

IMET, SMET, S-PMSI und Leaf werden anhand von Route Targets und gegebenenfalls Tag ID einer normalen BD oder SBD zugeordnet. Mehrere SBD-RTs, widersprüchliche normale BD-RTs oder ein tenantübergreifendes Gemisch sind fehlerhaft und müssen nach RFC 7606 als zurückgezogen behandelt werden.

Die Prüfung liegt am empfangenden PE, weil BGP-Zwischenknoten die EVPN-Semantik meistens nicht erkennen. Ein erfolgreicher Test sagt: Die Route passte in dieser Epoche zur lokalen Zuordnungstabelle.

Er sagt nicht, dass RT-Vergabe oder Originator autorisiert waren oder alle PEs dieselbe Tenant-Grenze kannten. Für die Untersuchung bleiben NLRI, RTs, Tag ID, Origin, Peer, Map und Entscheidung erhalten. „Installed“ ist nur das Ende der Klassifikation.

Die Aggregation spart Zustand und verliert Ursache

Ein PE verschmilzt IGMP/MLD-Zustände seiner normalen BDs und bestimmt daraus SBD-SMET. Ein (*,G) aus einer BD kann (S,G)-Bedarf einer anderen abdecken. Ein breiterer Eintrag zieht alle nötigen Flows an und reduziert Control-Plane-Einträge.

Im Aggregat ist nicht zwingend sichtbar, welche BD zuerst fragte, wie viele Empfänger übrig sind oder welcher Leave die letzte Begründung entfernt. Die Route kann korrekt bleiben, obwohl ein Großteil ihrer ursprünglichen Ursachen bereits verschwunden ist.

Ein Derivationsprotokoll hält beitragende ACs und BDs, Include/Exclude-Modus, Membership-Epochen, Regel, Advertised Key und Withdrawal-Bedingung fest. Dann bleibt Kompression reversibel.

Kompatibilität erzeugt angenommenes Interesse

Ohne IGMP/MLD Snooping gilt ein AC als an allen Flows interessiert. Ohne signalisierten RFC-9251-Support wird auch ein Remote-PE so behandelt. Diese Defaults schützen die Erreichbarkeit für weniger ausdrucksfähige Geräte.

Sie beobachten keinen Receiver. Ein OIF-Eintrag kann einen expliziten Join oder nur fehlende Negativinformation darstellen. Beides erzeugt Traffic, hat aber andere Konfidenz und andere Modernisierungswirkung.

Markieren Sie die Ursache als Report, Static Policy, No-Snooping-Default oder Legacy-Peer-Default. Gemessene Nachfrage und Compatibility Flooding dürfen in Kapazitätsplänen nicht gleich heißen.

Der Sicherheitsradius reicht über die Eingangs-BD hinaus

RFC 9625 beschreibt, dass ein Angreifer mit Zugang zu einer BD SMET-Routen auslösen und Ressourcen aller PEs der Tenant Domain beeinflussen kann. Falsche OISM-, IPMG-, MEG- oder PEG-Flags und Extended Communities können außerdem Verlust oder Umleitung verursachen.

Die Zulassung gehört daher vor die SBD-SMET-Erzeugung. Prüfen Sie Access Identity, Group und Source, Report-Rate, State-Limit, Wildcard-Recht und Tenant-Budget. Danach messen Sie Remote-Installationen und tatsächliche Ressourcenwirkung.

Auch der Abbau braucht einen Beleg: Leave oder Timeout, erneute Aggregation, BGP-Withdrawal, Konvergenz jedes Importers und freigegebene Ressourcen. Lokales Löschen beendet keine verteilte Schuld automatisch.

Eine Wahl erzeugt einen Gewinner, keine Vertrauensstellung

Für Non-OISM-Interworking gibt es IP Multicast Gateways. Kandidaten signalisieren Fähigkeit, benötigen IMET-Präsenz in der BD und wählen mit DF-Verfahren genau einen IPMG-DF. MEG und PEG übernehmen verwandte Grenzrollen.

Ein eindeutiger Gewinner verhindert doppelte Ausführung. Die RFC warnt dennoch, dass ein Angreifer mit Kontrolle über ein Gateway die Wahl beeinflussen und Multicast-Forwarding ändern kann. Algorithmische Eindeutigkeit ist kein Autorisierungsurteil.

Bewahren Sie Kandidaten, Flags, Routen, Algorithmus, Preferences, Winner, Management-Freigabe und Epoche. Auch ein einzelner Winner außerhalb der zugelassenen Menge ist ein Fehler.

OIF-Mitgliedschaft ist noch keine Ausgabe

Layer 2 wählt (S,G) oder ersatzweise (*,G), bestimmt die apparent source BD und wendet je nach Empfangsweg die OIF-Liste an. Darin stehen ACs, Tunnel und IRB; sie ändert sich mit Membership und Routen. Ein Layer-2-RPF-Check findet dabei nicht statt.

Bei Multihoming folgt die Eignungsprüfung. Mit ESI-Label muss das PE DF sein und darf den Frame nicht zum Ursprungssegment zurückschicken. Bei Local Bias zeigt die Remote-Ingress-Identität, ob das Segment bereits bedient wurde. Interner Traffic darf nicht über die SBD-IRB erneut verteilt werden.

Für einen konkreten Frame braucht man Selected State, apparent BD, OIF-Version, ESI/Local-Bias-Inputs, Suppressions und Transmits. Die Liste allein unterscheidet richtige Schleifenvermeidung nicht von falschem Auslassen.

Anycast zeigt die Grenze der Adressidentität

Existieren (*,G)-Empfänger in der Tenant Domain, verbietet RFC 9625 interne Anycast-Quellen für G. OISM würde beide (S,G)-Flows verteilen und könnte Duplikate zustellen. Dieselbe Source-Adresse macht zwei Aussendungen nicht zu einem Ereignis.

Prüfen Sie die Voraussetzung vor Aktivierung: Source-Inventar, Wildcard-State und Duplicate-Observation am Empfänger. Eine saubere Route beweist nicht, dass die unzulässige Topologie fehlte.

Die Belegkette folgt der Scope-Änderung

Sie beginnt mit Report, Access Identity, Port, AC, normaler BD, EVI, Segment, Tenant, Policy und Zeit. Danach folgen Membership-Transition und Multi-BD-Merge mit Beiträgern und Withdrawal-Bedingung. RTs, Tag ID, Origin, Import und Gateway-Wahlen bilden die Control-Plane-Stufe.

Für Daten verbindet sie Frame, apparent BD, State, OIF, Eligibility, Tunnel Copies, AC Transmits und Suppressions. Receiver Arrival, Copy Count, Application Consumption und Service Outcome bleiben spätere Tatsachen.

RFC 9625 vergrößert den Geltungsbereich von Interesse. Die Belegkette verhindert, dass zugleich dessen Bedeutung unbemerkt vergrößert wird.

Quellen