Zusammenfassung

  • RFC 10039 definiert D-PATH als optionales transitives BGP-Attribut mit Code 36 für konfigurierte EVPN/IPVPN-Interconnections und deren DOMAIN-ID-Folgen.
  • Eine eigene ID in der empfangenen Folge weist auf eine Domänenschleife hin; nach Local Preference kann die kürzere Folge gewinnen. Eine authentisierte Herkunfts- oder Zustellbestätigung entsteht dadurch nicht.
  • Belastbare Betriebsentscheidungen benötigen vier getrennte Nachweise: Identitätskonfiguration, Attributerhalt, RIB/FIB-Realisierung und Ende-zu-Ende-Prüfung im Mandantenkontext.

Die Route wusste mehr, als sie früher wusste

An einer Interconnection-Grenze war lange sichtbar, von welchem BGP-Nachbarn eine VPN-Route kam, aber nicht unbedingt, welche Gateway-Domänen sie als administrative Stationen durchlaufen hatte. D-PATH ergänzt genau diese Information. Das ist ein erheblicher Gewinn: Eine zurückkehrende Route kann an der eigenen DOMAIN-ID erkannt werden, bevor eine Domänenschleife weiterwächst.

Der zusätzliche Blick reicht aber nur bis zur BGP-Aussage. Wenn eine Route A → B → C trägt, ist belegt, dass die beteiligten Systeme diese Werte in der Aktualisierung transportierten. Nicht belegt ist, dass A, B und C korrekt abgegrenzt wurden, alle servicekritischen Attribute erhalten blieben oder der Datenpfad dem Kontrollpfad folgte.

Konfiguration ist die Wurzel der Domänenwahrheit

Ein D-PATH-Segment verbindet einen Inter-Service-AFI-Typ mit einer Folge von DOMAIN-IDs. Gateways derselben Domäne sollen denselben Wert verwenden; verschiedene Gateway-Domänen sollen unterschiedliche Werte führen. Die Werte sind opak und werden administrativ zugeteilt.

Hier liegt die erste Kontrollgrenze. BGP stellt nicht selbst fest, ob zwei Router organisatorisch derselben Domäne angehören. Es verhindert auch keine Kollision zwischen getrennten Betreibern. Werden in einer Domäne zwei IDs genutzt, kann eine echte Rückkehr unerkannt bleiben. Teilen zwei Domänen versehentlich eine ID, kann eine zulässige Route wie eine Schleife aussehen.

Das Attribut ist damit ein präziser Überbringer einer möglicherweise unpräzisen Konfiguration. Die autoritative Prüfung muss Gerätekonfigurationen, Gateway-Zuordnung und Änderungsstand vergleichen. Erst danach kann die beobachtete Folge sinnvoll bewertet werden.

Warum „transitiv“ nicht „unverändert“ heißt

Als optional transitive kann D-PATH einen BGP-Sprecher passieren, der das Attribut nicht versteht. Diese Eigenschaft verbessert seine Reichweite, bietet aber weder Signatur noch Echtheitsnachweis. Policy, fehlerhafte Serialisierung oder eine abweichende Implementierung können die Darstellung beeinflussen.

Auch das gewählte Interconnection-Modell entscheidet über die Erwartung. Im No-Propagate-Modell wird D-PATH nicht in die Nachbardomäne weitergegeben. Im Uniform Model bleibt die Domänenfolge über Grenzen hinweg erhalten. Deshalb ist ein fehlendes Attribut nicht ohne Kenntnis der Grenzkonfiguration als Fehler zu werten. Umgekehrt beweist ein vorhandenes D-PATH nicht, dass Route Targets, Labels, VNIs oder andere Serviceattribute ebenfalls korrekt ankamen.

Fehlerhaft formatierte Attribute werden gemäß RFC 10039 als treat-as-withdraw behandelt. Das schützt vor der Verwendung ungültiger Information, kann aber bei einem Softwarefehler viele Routen zugleich verschwinden lassen. Ein Rollout braucht daher echte Update-Mitschnitte und Withdraw-Zähler, nicht nur einen Haken „Code 36 unterstützt“.

Die kürzere Folge ist keine Qualitätsnote

In der Best-Path-Entscheidung wird die D-PATH-Länge nach Local Preference verglichen. Sind die vorherigen Kriterien gleich, gewinnt die Folge mit weniger DOMAIN-IDs. Fehlt D-PATH, gilt für diesen Vergleich eine Länge von null.

Die Zahl beschreibt weder Kilometer noch Latenz, Auslastung oder Vertrauensniveau. Eine höhere Local Preference kann bewusst einen längeren Weg bevorzugen. Und selbst die ausgewählte Route kann vor der FIB-Programmierung scheitern, auf einen unaufgelösten Next Hop zeigen oder mit einem falschen Label beziehungsweise VNI verbunden sein.

Der Auswahlgrund und die Servicewirkung gehören deshalb in getrennte Felder eines Betriebsberichts. Nur so bleibt erkennbar, ob eine Änderung die Kontrollentscheidung, die Weiterleitungsrealisierung oder die Erfahrung des Mandanten getroffen hat.

Vier Belege für eine belastbare Aussage

Zuerst werden alle DOMAIN-IDs aus den Gateways ausgelesen. Gleichheit innerhalb einer Domäne und Eindeutigkeit zwischen Domänen werden gegen Inventar und genehmigte Änderung geprüft.

Danach werden eingehende und ausgehende BGP-Updates an jeder Grenze verglichen. D-PATH, Servicetyp und die übrigen VPN-Attribute müssen als Paket betrachtet werden. Eine Momentaufnahme der finalen Tabelle kann nicht zeigen, an welcher Grenze Information verloren ging.

Im dritten Schritt wird die Route vom Empfang über die RIB-Auswahl bis zur FIB verfolgt. Next-Hop-Auflösung, Label, VNI und Tunnelzustand werden am tatsächlich weiterleitenden System geprüft.

Zum Schluss folgt ein Hin- und Rücktest aus dem VRF oder einem gleichwertigen Mandantenkontext. Ein Ping aus dem Managementnetz kann Isolation und Rückweg nicht vertreten. Erst diese Beobachtung stützt die Aussage, dass Zustellung stattgefunden hat.