Zusammenfassung

  • RFC 7911 ermöglicht mehrere Pfade für ein Präfix, indem jede NLRI nach passender Sende- und Empfangsaushandlung für die Adressfamilie eine vier Oktett lange Kennung erhält.
  • Die Kennung ist undurchsichtig und lokal, kein Präferenzsignal. Der Empfänger behält seine Best-Path-Entscheidung und trägt zugleich mehr Speicher-, Verarbeitungs-, Neustart- und Beobachtungskosten.

Ein Pfad war Antwort und Grenze zugleich

Basis-BGP kündigt einem Nachbarn höchstens eine Route je NLRI an. Eine neue Route für dasselbe Präfix ersetzt die alte implizit. Das vereinfacht den Austausch, bindet die Sicht des Empfängers aber an die Auswahl des Senders: Eine nie exportierte Alternative kann er nicht verwenden.

ADD-PATH trennt diese Funktionen. Im erweiterten UPDATE steht der vier Oktett lange Path Identifier vor der NLRI. Das Paar aus Präfix und Kennung bezeichnet eine angekündigte Route, sodass mehrere Pfade gleichzeitig bestehen können. Eine spätere Ankündigung mit demselben Paar ersetzt genau diesen Pfad; ein Withdraw entfernt ihn. Der Rückzug einer nie angekündigten Kennung soll still ignoriert werden.

Die Kennung wird vom Sender vergeben und gilt nur gegenüber diesem Nachbarn. Wer die Route weitergibt, muss eine eigene Kennung vergeben. Der Empfänger darf aus einer höheren Zahl weder bessere Qualität noch Alter, Sicherheit oder globale Stabilität ableiten. Es ist Identität, kein Urteil.

Die Entscheidungshoheit bleibt damit lokal. Der Sender wählt nach eigener Policy, welche Alternativen er zeigt; der Empfänger führt seine eigene Auswahl aus. RFC 7911 empfiehlt, bei mehreren Pfaden die beste Route des Senders einzuschließen, außer sie kam vom selben Nachbarn. Auch dann ist „beste“ nur das lokale Ergebnis des Senders, keine Anweisung.

Die Erlaubnis ist asymmetrisch und familienspezifisch

ADD-PATH verwendet Capability Code 69. Der Wert enthält ein oder mehrere Tupel aus AFI, SAFI und Send/Receive. 1 bedeutet Empfangen, 2 Senden und 3 beides; andere Werte gelten als unverstanden.

Mehrere Pfade dürfen nur gesendet werden, wenn der Sprecher für dieselbe AFI/SAFI Senden angekündigt und vom Nachbarn Empfangen erhalten hat. Die Gegenrichtung kann abweichen. Die Erlaubnis ist weder ein sitzungsweiter Schalter noch eine Vermutung über Software, sondern die ausdrückliche Schnittmenge aus Peer, Richtung und Familie.

Der Sender gewinnt die Macht, mehr Alternativen sichtbar zu machen. Der Empfänger kann diese Information für Konvergenz, Route-Reflector-Diversität oder andere lokale Zwecke nutzen. Er trägt jedoch einen Teil der Kosten: Jeder angenommene Pfad braucht Zustand und Verarbeitung; viele Pfade für viele Präfixe können Ressourcen belasten.

Der Standard nennt keine allgemeine Pfadzahl oder Speichergrenze. Eine erfolgreiche Capability-Aushandlung erlaubt das Format, beweist aber weder korrekte Policy noch korrektes Forwarding oder Wiederanlaufverhalten.

Lokale Identität erschwert Neustartnachweise

Path Identifier müssen einen Control-Plane-Neustart nicht überstehen. Eine Kennung vor dem Neustart ist daher nicht automatisch derselbe Pfad danach. Bei Graceful Restart kann Forwarding-Zustand bestehen bleiben, während Ankündigungen und lokale Kennungen neu entstehen.

Auch Telemetrie braucht den Capability-Kontext. Dieselben UPDATE-Bytes werden unterschiedlich gelesen, je nachdem, ob ADD-PATH für die Familie ausgehandelt wurde. Ein passiver Analysator ohne OPEN kann die Kennung als NLRI-Daten missverstehen und ein scheinbar sicheres, falsches Ergebnis liefern.

RFC 7911 definiert Kodierung, Richtungen, Ersatz, Withdrawals und Ressourcenrisiken. RFC 4271 liefert das Grundmodell, RFC 5492 den Capability-Rahmen, IANA Code 69 und RFC 4272 die zugrunde liegenden BGP-Risiken. Die Ordnung nach Macht, Nutznießern und Kosten ist Analyse.

Die Quellen belegen keinen Einsatz bei einem benannten Betreiber, schreiben keine universelle Pfadzahl vor und setzen keinen allgemeinen sicheren Schwellenwert. Sie machen Kennungen nicht dauerhaft oder global und garantieren keinen Nutzen in jeder Topologie.

Quellen