Zusammenfassung

  • Eine Domäne nach RFC 10039 wird durch das Weiterleitungsverhalten im Adressraum eines Mandanten bestimmt. AS, IGP-Instanz, Standort und Organisation sind keine verlässlichen Abkürzungen.
  • Ein DOMAIN-ID-Eintrag ist wirksam: Eine lokale Übereinstimmung in D-PATH kennzeichnet eine zurückgekehrte Route, und die Attributlänge beeinflusst die Auswahl. Falsche Zuordnungen können deshalb echte Routen verwerfen oder echte Schleifen übersehen.

Beide redundanten Gateways hatten die neue Funktion aktiviert. Das erste verwendete eine DOMAIN-ID für die gesamte Verbindung, das zweite je eine pro Mandanten-VRF. BGP blieb Established, alle Werte waren syntaktisch gültig. Erst eine Rückroute zeigte, dass die Geräte nicht dieselbe Domäne meinten.

Die Ursache lag nicht im Attribut, sondern im fehlenden gemeinsamen Grenzmodell.

RFC 10039 beschreibt die Kopplung von EVPN- und IPVPN-Domänen für die Weiterleitung zwischen Mandantensubnetzen. Ein Interworking PE übernimmt eine Route in eine IP-VRF und originiert sie mit den für die Nachbardomäne passenden Adressfamilien und Kapselungsmerkmalen neu. Bei redundanten Gateways kann eine von IPVPN nach EVPN übersetzte Route über ein zweites Gateway wieder nach IPVPN gelangen. D-PATH hält die durchlaufenen Domänen fest, damit eine solche Kontrollschleife erkannt wird.

Die Aufzeichnung setzt jedoch voraus, dass alle Beteiligten dieselben Namen für dieselben Grenzen verwenden.

Eine Domäne folgt dem Datenpfad

Zwei PEs gehören zur selben Domäne, wenn sie denselben Mandanten bedienen und der Verkehr zwischen ihnen auf keinem Transitrouter eine IP-Suche im Adressraum dieses Mandanten benötigt. Wo eine solche Suche erforderlich wird, verbindet ein Gateway unterschiedliche Domänen.

Der RFC trennt diese Definition ausdrücklich von AS- und IGP-Grenzen. Eine Domäne kann mehrere Autonome Systeme umfassen; ein AS kann mehrere Domänen enthalten. Auch Rechenzentrumsname, Region oder Betriebszuständigkeit sind nur Planungshilfen. Ob die gezeichnete Grenze stimmt, entscheidet der konkrete Forwarding-Pfad.

Die sechs Oktette der DOMAIN-ID können irreführen. Vier Oktette bilden den Global Administrator, zwei den Local Administrator. Im globalen Feld darf eine öffentliche oder private ASN, eine IPv4-Adresse oder ein anderer Wert stehen. Das erleichtert eindeutige Vergabe und Fehlersuche. Es macht aus der ID weder eine ASN-Aussage noch einen authentisierten Eigentumsnachweis.

Der Standard verlangt stattdessen gemeinsame Konfiguration. Jede Domäne braucht eine eindeutige ID, alle daran angeschlossenen Gateway PEs müssen denselben Wert führen, und ein Gateway zwischen zwei Domänen verwendet zwei unterschiedliche Werte. Die Vergabe kann für eine ganze Interconnection oder je Mandanten-IP-VRF gelten. Beim Route Leaking zwischen VRFs entscheidet dieser Kontext darüber, gegen welche lokalen IDs die empfangene Route geprüft wird.

Aus einer Bezeichnung wird eine Routingentscheidung

D-PATH ist ein optionales transitives BGP Path Attribute und bei der IANA als Code 36 registriert. Ein Eintrag verbindet die DOMAIN-ID mit einem ISF_SAFI_TYPE. Dieser macht sichtbar, ob ein Abschnitt EVPN, IPVPN oder eine vorgesehene lokale Kennzeichnung verwendet hat.

Für die Schleifenerkennung ist der SAFI-Wert nicht maßgeblich. Enthält ein empfangener D-PATH irgendeine DOMAIN-ID, die lokal mit der betreffenden IP-VRF verbunden ist, gilt die Route für die entsprechenden Verfahren als zurückgekehrt. Das gilt auch bei unbekanntem oder abweichendem SAFI-Typ.

Die Regel verhindert, dass ein Wechsel der Familie die Rückkehr verschleiert. Sie kann aber eine Kollision nicht von einer tatsächlichen Rückkehr unterscheiden. Zwei getrennte Domänen mit derselben ID erzeugen eine falsche Schleifenerkennung. Zwei Namen für dieselbe Domäne lassen die echte Schleife passieren. Ein falscher VRF-Scope vergleicht andere Objekte als die, die der Change Owner im Kopf hatte.

D-PATH greift außerdem in die Pfadauswahl ein. Nach LOCAL_PREF werden bei konkurrierenden EVPN- und Nicht-EVPN-ISF-Routen die Kandidaten ohne kürzesten D-PATH entfernt; ein fehlendes Attribut zählt als Länge null. Die Zahl misst weder physische Entfernung noch Latenz, Last, Preis oder Vertrauenswürdigkeit. Sie zählt konfigurierte Domänendurchläufe und kann trotzdem den Gewinner bestimmen.

Eine CLI-Ausgabe ist daher kein Wahrheitsbeleg. Sie zeigt, dass eine Behauptung transportiert wurde. Erst die Verbindung mit RIB, Auswahl, FIB und Paketbeobachtung zeigt ihre Wirkung.

Abschotten oder Herkunft erhalten

D-PATH ist standardmäßig deaktiviert und darf nur IPVPN- und EVPN-Routen begleiten. An der Grenze stehen zwei unterschiedliche Betriebsweisen zur Verfügung.

No Propagation Mode ist der Default. Beim Neuoriginieren setzt das Gateway die BGP-Attribute zurück und überträgt D-PATH nicht. Dadurch erreicht weniger fremder Zustand die nächste Domäne. Redundante Gateways können allerdings weiterhin eine Schleife bilden; Policies oder eine Route-Origin-Community mindern einzelne Risiken, ohne jede Konstellation abzudecken.

Uniform Propagation Mode erhält eine begrenzte Menge gemeinsam nutzbarer Attribute: AS_PATH, den anwendbaren D-PATH und bestimmte iBGP-interne Werte. Weitere Attribute sollten nur mit ausdrücklicher Import- oder Exportfreigabe die Grenze überschreiten. Das erhöht die Nachvollziehbarkeit und zugleich die Reichweite syntaktisch korrekter, aber semantisch unpassender oder absichtlich falscher Informationen.

Die Wahl ist keine pauschale Sicherheitsrangliste. No Propagation gewinnt Isolation und verliert Herkunft. Uniform Propagation gewinnt Herkunft und übernimmt Prüfpflichten. Für jede Grenze müssen Modus, Attribut-Allowlist, Ausnahmeverantwortung und Rückweg dokumentiert sein.

Fehlerbehandlung heilt keine falsche Karte

Beschädigte Strukturen werden klar behandelt. Ein zu kurzer oder fehlerhafter D-PATH sowie das Attribut in einer unzulässigen AFI/SAFI-Kombination lösen nach RFC 7606 treat-as-withdraw aus. Unbekannte SAFI-Typen dürfen akzeptiert werden. Taucht D-PATH mehrfach in einem UPDATE auf, bleibt der erste erhalten und die übrigen werden verworfen.

Diese Regeln begrenzen Codierungsfehler. Eine gut geformte, aber falsch vergebene ID bleibt unsichtbar. RFC 10039 warnt ausdrücklich vor falscher Schleifenerkennung, Verkehrsausfall sowie suboptimalem oder uneinheitlichem Routing bei fehlerhaften DOMAIN-IDs oder uneinheitlicher Unterstützung. Als transitives Attribut kann D-PATH zudem absichtlich falsche Domäneninformationen über mehrere administrative Grenzen tragen.

Auch die Außengrenze ist zu prüfen. D-PATH gehört in den abgeschlossenen VPN-Bereich. Ein konformes PE entfernt es, bevor es ein Präfix als SAFI-1-Unicast an einen CE ankündigt. Aktualisierte Geräte sollten lokale Regeln für D-PATH-Routen von nicht aktualisierten Peers besitzen. Wie dieser Peer-Status festzustellen ist, lässt der RFC offen. Nur Versionsinventar und Versuch liefern eine belastbare Antwort.

Grenzabkommen plus Rollout-Beleg

Vor dem ersten Kommando braucht jeder Mandant ein Grenzabkommen. Es nennt den Weiterleitungstest, der die Domänen trennt, die Vergabestelle, den Eindeutigkeitsraum, die Kollisionsprüfung, alle Gateway PEs sowie die genaue Bindung an Schnittstellen und IP-VRFs. ASN- oder Adressschreibweisen werden ausdrücklich als Namenskonvention, nicht als Topologiebeweis festgehalten.

Der Rollout-Beleg ergänzt Softwarestände und getestete Unterstützung, den Modus je Grenze, erlaubte Attribute, Regeln für lokale Routen, das Verhalten alter Peers, Beobachtungsfenster, Abbruchschwelle und unabhängigen Rollback. Für ein Testpräfix muss vorab feststehen, welcher D-PATH an jedem Hop erwartet wird.

Negative Tests sind unverzichtbar. Eine legitime Route durchläuft die geplante Folge. Eine Route mit lokaler ID aktiviert die Rückkehrerkennung. Ein unbekannter SAFI-Typ darf die Identitätsprüfung nicht umgehen. Eine defekte Struktur wird begrenzt zurückgezogen. Ein älterer Peer zeigt sein tatsächliches Verhalten. Am CE-Ausgang beweist ein Capture, dass SAFI 1 kein D-PATH mehr trägt.

Dasselbe Canary-Präfix wird durch Adj-RIB-In, Kandidatensatz, Auswahl, FIB und Paketpfad verfolgt. Established beweist keine Funktion. Gespeicherte Konfiguration beweist keine gemeinsame Bedeutung. Ein sichtbarer Wert beweist keine Schleifenfreiheit. Erst das zusammenhängende Ergebnis erlaubt die enge Aussage, dass diese Gateways an diesem Tag dieselbe Domäne meinten und die erwarteten Wege trennten.

RFC 4271 liefert das BGP-Grundverfahren, RFC 4364 den IPVPN-Kontext, RFC 7432, RFC 9135 und RFC 9136 die EVPN-Bausteine. Keiner dieser Texte belegt die Implementierung eines bestimmten Herstellers oder den Zustand eines konkreten Netzes.

Quellen