Zusammenfassung

  • RFC 7911 ergänzt ein Prefix um einen lokalen vier-octet Path Identifier. Damit können mehrere Anzeigen in einer ausgehandelten Richtung gleichzeitig bestehen.
  • Der Sender bestimmt die sichtbare Menge; der Empfänger behält Import, Best-Path, Multipath und FIB. Der Identifier ist weder Rang noch dauerhafte globale Identität oder Diversitätsbeleg.
  • Ein sicherer Einsatz beweist effektive AFI/SAFI-Richtung, genaue Sende- und Empfangsmengen, Zustandskosten, einzelne Withdrawals und Forwarding. Mehr sichtbare Pfade bedeuten nicht automatisch mehr nutzbare Ausgänge.

Route Reflection ist Informationskompression. In einem vollständigen iBGP-Mesh hört jeder Speaker Kandidaten direkt. Der Reflector reduziert Sessions und übermittelt üblicherweise den Pfad, den er selbst als besten auswählt. Der Client erhält das Ergebnis, nicht sämtliche Entscheidungsgrundlagen.

Diese Einsparung ist oft sinnvoll. Sie wird zum Risiko, wenn der verborgene Pfad die Import-Policy des Clients bestanden hätte, einen Ausfall überlebt oder aus dessen IGP-Perspektive günstiger gewesen wäre. Eine stabile BGP-Sitzung beweist nicht, dass die vorhandenen physischen und kommerziellen Optionen sichtbar sind.

Klassisches BGP verschärft die Kompression. Eine neue Anzeige desselben NLRI vom selben Nachbarn ersetzt die vorige implizit. Das Prefix ist der Schlüssel. Ohne Erweiterung kann eine Sitzung nicht zwei gleichzeitige Routen desselben Prefixes getrennt verwalten.

RFC 7911 setzt einen vier-octet Path Identifier vor das NLRI. Der wirksame Schlüssel wird zum Paar aus Prefix und Identifier. Eine neue Anzeige desselben Paares ersetzt nur diesen Pfad; ein Withdrawal entfernt nur ihn. Ein unbekannter Identifier in einem Withdrawal soll ignoriert werden und darf nicht alle Pfade des Prefixes löschen.

Die Zahl ist lokal. Der ankündigende Speaker vergibt sie für diese Beziehung. Bei erneuter Ankündigung erzeugt ein Speaker seinen eigenen Wert und transportiert keinen Upstream-Identifier als Ende-zu-Ende-Label. Nach einem Neustart dürfen sich die Werte ändern. Größe und Reihenfolge sagen nichts über Präferenz, Herkunft, Alter oder Qualität.

Der Identifier taugt deshalb als Protocol-Buchhaltung, nicht als Geschäftsidentität. Ein Collector, der „Pfad 19“ über zwei Reflectors verbindet, erfindet eine Beziehung. Ein Restart-Test, der dieselbe Zahl fordert, verwechselt Token-Kontinuität mit Routen-Kontinuität. Verglichen werden Attribute, Rolle, Next Hop und Forwarding.

Capability Code 69 ist gerichtet. Jedes Tuple enthält AFI, SAFI und receive, send oder both. Multiple-Path-Encoding gilt in einer Richtung nur, wenn der Sender send und der Empfänger receive für dieselbe Familie angekündigt haben. Die Gegenrichtung kann klassisch bleiben.

So kann IPv4 Unicast auf einer Sitzung nur ausgehend ADD-PATH nutzen, während IPv6 oder die Rückrichtung single-path bleibt. Ein Reflector kann Alternativen zeigen, ohne alle Kandidaten der Clients anzunehmen. „ADD-PATH aktiv“ beschreibt dieses Berechtigungsmodell nicht.

Capability erlaubt Transport, wählt aber keine Menge. RFC 7911 empfiehlt die beste Route einzuschließen, außer sie stammt vom Zielnachbarn, verlangt jedoch nicht alle Pfade. Implementierungen können all, N-best, best pro Nachbar-AS, multipath-fähige oder policydefinierte Pfade senden.

Diese Auswahl schafft oder vernichtet den Nutzen. Zwei Routen mit demselben Next Hop, Standort, Line Card, Provider und Kabelkanal erhöhen Zustand, aber nicht Ausfallsicherheit. Best pro Nachbar-AS kann kommerzielle Diversität liefern und trotzdem dieselbe Faser nutzen. Identifier zählen Control-Plane-Objekte, keine unabhängigen Fehlerdomänen.

RFC 7964 zeigt den Trade-off im engeren Fall MED-bedingter dauerhafter Oszillation. All available paths nähert sich der Informationskonsistenz eines Full Mesh mit hohem Zustand. Group Best beschränkt sich unter Topologiebedingungen auf den besten Pfad je Nachbar-AS. Diese Begrenzung löst einen bestimmten Mechanismus und ist kein Universalrezept.

Der Empfänger bleibt souverän. Er kann Anzeigen filtern, einen Best Path wählen, ein Multipath-Set bilden oder Reserven außerhalb der FIB halten. RFC 7911 verändert den Decision Process aus RFC 4271 nicht. Vier empfangene Pfade schalten weder ECMP ein noch zwingen Hardware zur Installation.

Vier Adj-RIB-In-Einträge beweisen daher keine vier Ausgänge. Einer kann abgelehnt, ein Next Hop unauflösbar und zwei können auf dieselbe FIB-Adjacency rekursieren. Selbst das Loc-RIB kann mehr auswählen als die Plattform programmiert. Der Nachweis muss Policy, Entscheidung, Rekursion, FIB und Paketbeobachtung durchlaufen.

Path Hiding an einem IXP Route Server zeigt die Wirkung. RFC 7947 beschreibt, dass der Server einen Pfad auswählt, den die Policy eines bestimmten Clients ablehnt, während ein anderer vorhandener Kandidat zulässig wäre. Sendet der Server nur seine Wahl, bleibt der Client ohne Route. Seine Policy arbeitet korrekt auf einer künstlich engen Eingabe.

ADD-PATH kann die Eingabe verbreitern. RFC 7947 warnt aber, bidirektionaler Einsatz könne inaktive, ungültige oder suboptimale Client-Routen verbreiten. Für diesen Fall empfiehlt es einen send-only Route Server und receive-only Clients. Das ist eine Vertrauensgrenze des IXP, nicht die Vorlage für jeden internen Reflector.

Innerhalb eines AS können unterschiedliche Client-Mengen gewollt sein. Leistungsfähige Edge Router brauchen vielleicht mehr Diversität, kleinere Geräte eine niedrige Grenze. Jede Abweichung benötigt Rolle, Address Family, Algorithmus, Maximum und erwartetes Konvergenzmodell. Sonst lässt sich im Störungsfall kein Sichtbarkeitsanspruch rekonstruieren.

Zusätzlicher Zustand kostet. RFC 7911 nennt Speichererschöpfung und netzweite Instabilität. Jeder Pfad erweitert RIB, Attribute, Policy-Arbeit, Updates und Telemetrie. Eine im Normalbetrieb ruhige Reserve kann beim Ausfall eine Welle von Entscheidungen und Withdrawals auslösen.

RFC 6774 erreicht mit einer anderen Verteilungsarchitektur dieselbe Grenze. Weniger Path Starvation und vorher bekannte Backups erfordern Kopien und Verarbeitung. Sichtbarkeit ist Ressourcenverteilung mit Budget, Zulassung und messbarem Nutzen.

Produkte trennen die Schichten. Cisco unterscheidet Capability, Additional-Path-Selection und Advertisement. Junos trennt send/receive-Konfiguration vom ausgehandelten Zustand. FRRouting bietet all, per-AS-best, N-best und Receive Limits. Das sind Produktbeispiele, aber sie benennen die Felder eines belastbaren Change Records.

Der erste Beleg ist eine Matrix je Nachbar und AFI/SAFI: lokal angekündigte Modi, remote empfangene Modi und effektive Richtung. Danach folgen Sender-Algorithmus, Maximum, Exportfilter, Aufnahme des normalen Best Path und Unterschiede zwischen Clients.

Die Baseline speichert Mengen, nicht bloß Zahlen. Im Adj-RIB-Out: Prefix, lokaler Path Identifier, Next Hop, AS_PATH, Origin, MED, Communities und Auswahlgrund. Beim Empfänger: Adj-RIB-In, Importentscheidung, Best-Path-Grund, Multipath, Loc-RIB und FIB. Identifier verschiedener Speaker sind niemals globale Schlüssel.

Replacement und Withdrawal verwenden den vollständigen Schlüssel. Neue Attribute für dasselbe Paar ändern nur diesen Pfad. Das Withdrawal eines Identifiers lässt Geschwister bestehen. Ein unbekannter Wert entfernt nichts. So werden Collectors und Automation erkannt, die fälschlich nur nach Prefix arbeiten.

Beim Restart müssen Zahlen nicht stabil bleiben. Alte Identifier müssen verschwinden, erwartete Alternativen rechtzeitig wiederkommen und kein verwaister Pfad in der FIB bleiben. Das stabile Beweisobjekt ist die Beziehung aus Route, Policy und nutzbarem Forwarding.

Diversität wird nach Fehlerdomäne bestimmt: Next Hop, Nachbar-AS, Standort, Line Card, Link, Provider, Kabelweg und Policy. Fehlen Daten, lautet das Ergebnis unbekannt. Zwei Token verwandeln Unwissen nicht in Redundanz.

Der abschließende Test entfernt den bevorzugten Ausgang. Beobachtet werden Wechsel auf eine bereits sichtbare Alternative, Update-Volumen, Entscheidungszeit, Next-Hop-Auflösung, FIB-Programmierung und Paketverlust. Auch gefilterte, unauflösbare und gemeinsam ausfallende Kandidaten werden geprüft.

Kapazität ist ein Zulassungsvertrag. Grenzen je Peer, Family und Prefix, Speicher, Update-Rate, Telemetrieaufbewahrung und Überschreitungsverhalten werden vorab festgelegt. Willkürliches stilles Verwerfen erzeugt Path Hiding hinter einer erfolgreichen Capability-Anzeige neu.

Rollback ist mehr als eine Config-Zeile. Die Menge muss schrumpfen, alte Identifier und FIB-Reste müssen verschwinden. Erfordert die Neuverhandlung einen Session Reset, gehört das Reachability-Risiko in die ursprüngliche Genehmigung.

Heng Lus Prinzip der minimalen Anfangsspezifikation passt zur Grenze. Gemeinsam sind nur gerichtete Capability und lokaler Diskriminator. Sichtbare Menge, Empfangsbudget und FIB-Auswahl bleiben lokal. Interoperabilität verlangt keine Zentralisierung künftiger Policy.

Running-Code-Primacy ordnet die Belege. Konfiguration ist Absicht. Ausgehandelte Capability, gesendetes Tuple, akzeptierte Route, Auswahlgrund, programmierter Next Hop und beobachtetes Paket sind zunehmend stärkere Tatsachen. Ohne diese Kette existiert keine operative Alternative.

Datensouveränität wird zur Sichtbarkeitshoheit. Der Sender kontrolliert die Offenlegung, der Empfänger die Nutzung und das physische Netz den Ausgang. Eine Pfadzahl hebt diese getrennten Zuständigkeiten nicht auf.

ADD-PATH befiehlt nicht, alles zu senden, und garantiert keine Resilienz. Es verhindert, dass eine reine Prefix-Identität alle Alternativen einer Sitzung verdrängt. Wert entsteht nur durch eine gewollte, begrenzte, erklärbare Menge, aus der nach Ausfall des bevorzugten Pfads reales Forwarding wird.

Quellen