Zusammenfassung

  • BGP-LS leitet Node-, Link- und Prefix-Objekte aus IGP-/TE-Informationen ab und veröffentlicht eine physische, abstrahierte oder gemischte Sicht unter Policy. Es exportiert weder das LSDB wortgetreu noch dessen LSA/LSP-Sequenznummern.
  • Eine Established Session und redundante Producer beweisen keine Aktualität. Jede Entscheidung muss Quelle, Protocol-ID, Instance-ID, Withdrawals, Attribute, Consumer-Merge, Berechnungsstand sowie FIB- und Paketresultat verbinden.

Im ersten Lagebild war alles grün: BGP-Nachbarn standen, die Objektzahl blieb stabil, der Controller meldete eine erfolgreiche Berechnung. Nur der Datenverkehr erreichte das andere Ende nicht. Die Topologie hatte eine Verbindung behalten, die das Netz bereits verloren hatte.

Nach der Partition sah Producer A noch A–B, Producer B noch B–A. Keine einzelne Quelle beschrieb einen vollständigen, aktuellen Link. Erst der Merge im Consumer machte aus zwei alten Fragmenten eine ganze Kante.

RFC 9552 behandelt genau dieses Risiko bei redundanten Producern und unerreichbaren Ursprungsnodes. Der Standard vom Dezember 2023 ersetzt RFC 7752 vollständig und übernimmt die Aktualisierungen aus RFC 9029. Er macht deutlich: BGP-LS verteilt eine kontrollierte Darstellung der Topologie, keine beglaubigte physische Wahrheit.

Aus dem LSDB abgeleitet heißt nicht mit dem LSDB identisch

Ein Producer gewinnt Informationen üblicherweise aus einem OSPF- oder IS-IS-LSDB und einer Traffic Engineering Database. Daraus bildet er Node-, Link- und Prefix-NLRI sowie BGP-LS-Attribute. Ein exportiertes Objekt kann Inhalte mehrerer LSA oder LSP vereinen; deren ursprüngliche Sequenznummern werden nicht mitgeführt.

Die Darstellung ist deshalb ein neues Beweisobjekt. Gealterte, gelöschte, fehlerhafte oder vom Quellprotokoll ignorierte Informationen werden nach dessen Regeln behandelt. Nicht jedes Feld muss exportiert werden, und Policy kann Inhalt wie Zeitpunkt der Origination steuern.

Abweichung kann gewollt sein. RFC 9552 erlaubt eine physische Topologie, eine Abstraktion aus aggregierten Nodes und virtuellen Pfaden oder eine Mischung. Ein ALTO-Consumer benötigt möglicherweise eine gröbere Cost Map als ein PCE. Erst der genehmigte Disclosure-Vertrag entscheidet, ob eine Differenz zulässig, veraltet oder verloren ist.

Dieser Vertrag muss Source-Domains, Objekte, Attribute, Abstraktionsgrad, Aktualisierungsziel, Freshness-Grenze, Vertraulichkeit und Zweck benennen. Ohne ihn wird „Topologie“ zu einem Begriff ohne Eigentümer und Zeitbezug.

Drei Rollen, drei nachweisbare Übergaben

RFC 9552 unterscheidet Producer, Propagator und Consumer. Der Producer originiert Link-State-Information in BGP, meist aus einem IGP, aber auch aus Direct- oder Static-Quellen. Der Propagator verarbeitet UPDATEs, durchläuft den BGP Decision Process und verteilt die Auswahl. Der Consumer ist die nutzende Anwendung und muss kein BGP-Speaker sein.

Ein System kann Rollen kombinieren, doch der Audit-Trail darf sie nicht vermengen. Er muss zeigen, wer ein Objekt ableitete, wer es unter welcher Policy veröffentlichte, welcher BGP-Pfad gewählt wurde, was der Nachbar erhielt, wie Duplikate behandelt wurden und welche Anwendung daraus handelte.

Die Schnittstelle vom BGP-Speaker zum Consumer ist unidirektional. Der Consumer darf dort keine Informationen zur BGP-LS-Origination zurückspeisen. Lesen und Schreiben bleiben getrennte Befugnisse. Änderungen am Netz benötigen eine eigene authentisierte Southbound-Schnittstelle.

Damit zerfällt der einfache Pfeil „IGP → BGP-LS → Controller“ in mehrere Entscheidungen: Source-Annahme, Derivation, Export, BGP-Selektion, Merge, Berechnung, Genehmigung, Geräteprogrammierung und Verifikation.

Instance-ID ist eine Identitätsgrenze

Non-VPN BGP-LS verwendet AFI 16388 / SAFI 71, VPN Link-State SAFI 72. RFC 4760 liefert Multiprotocol Capability sowie MP_REACH und MP_UNREACH. Eine ausgehandelte Capability beweist nur den Austauschkanal.

Protocol-ID unterscheidet IS-IS L1/L2, OSPFv2, OSPFv3, Direct und Static. Die acht Oktett lange BGP-LS Instance-ID trennt IGP-Instanzen. Alle Producer einer Domain müssen dieselbe Instance-ID nutzen; verschiedene Domains benötigen eindeutige Werte. Andernfalls wird eine Topologie dupliziert oder zwei Domains werden zusammengezogen.

ASN, Area, Router-Identität, Topology-ID und Descriptor-TLVs vervollständigen den Schlüssel. Inkonsistente optionale TLV bei redundanten Producern können zusätzliche NLRI oder unvollständige Attribute erzeugen.

Eine Descriptor-Änderung ist kein Update am selben Schlüssel. Der alte NLRI muss mit MP_UNREACH zurückgezogen und der neue angekündigt werden. Erfolg verlangt positive und negative Evidenz: Der neue Schlüssel ist vorhanden, der alte aus Producer, RIB, Adj-RIB-Out und Consumer-Graph verschwunden.

BGP wählt einen Pfad, nicht die physische Wahrheit

Der Decision Process aus RFC 4271 kann zwischen redundanten Kopien wählen. Seine Kriterien sagen jedoch nichts darüber, welcher Producer den Ursprung zuletzt tatsächlich erreichen konnte. Best Path ist Protokollpräferenz, kein Freshness-Zertifikat.

Beim Geisterlink waren die Feeds nicht zwei vollständige Beobachtungen. Sie waren komplementäre alte Hälften. Der Consumer erzeugte beim Zusammenführen eine Aussage, die keine Quelle alleine tragen konnte. Quellenzahl und Aktualität sind daher getrennte Messgrößen.

Benötigt werden Ursprungserreichbarkeit je Producer, LSA/LSP-Identität und Alter, LSDB/TED-Epoch, Origination-Zeit, selected und alternate paths, erwartete Withdrawals und Merge-Zustand. Eine grüne Session beantwortet keine dieser Fragen.

RFC 9552 empfiehlt, Objekte unerreichbarer Ursprungsnodes zurückzuziehen, außer ein expliziter Anwendungsfall verlangt eine vollständige, gehaltene LSDB-Sicht. Die Ausnahme braucht Zweck, Eigentümer, Altersgrenze und sichtbare Kennzeichnung; sie darf kein stiller Dauerzustand werden.

Ein vorhandener NLRI kann verlorene Eigenschaften verbergen

Die Objektidentität steht im NLRI, viele Eigenschaften im BGP-LS Attribute. Im Fehlerkontext von RFC 7606 kann ein fehlerhaftes Attribut verworfen werden, während der NLRI bestehen bleibt.

Das ist ein sichtbarer Verlustzustand, keine absichtliche Aussage „Link ohne Metrik“. Consumer müssen policy-bedingte Auslassung, unbekannte weitergereichte TLV, Error-bedingten Attribute Discard und tatsächlich nicht definierte Werte unterscheiden.

Große Attributmengen können Extended Messages nach RFC 8654 erfordern. Unterschiedliche Capabilities oder TLV-Ausschlüsse führen bei gleichem NLRI zu verschiedenen Beweisgrundlagen. Verglichen werden müssen vollständige Attribut-Fingerprints.

Das IANA-Register belegt Definition und Status von Codepoints. Es belegt nicht die korrekte Erfassung oder physische Aktualität eines konkreten Objekts.

Empfang ist keine Ausführungsvollmacht

Die PCE-Architektur braucht Topologie/TED-Daten, ALTO kann abstrahierte Network- und Cost-Maps nutzen, und RFC 8571 definiert TE-Performance-Metriken in BGP-LS. Keine dieser Anwendungen macht den Feed zur Genehmigung eines Pfades.

Die Nachweiskette beginnt bei LSA/LSP, Quellprotokoll, Ursprungserreichbarkeit und Epoch. Am Producer werden Software, Protocol-ID, Instance-ID, Descriptor, Policy sowie Origination und Withdrawal erfasst. Bei der Propagation folgen Capability, UPDATE, Auswahl, Alternativen, Attribute Discard und Verzögerung. Der Consumer friert Objektmenge, Merge-Regel, fehlende Eigenschaften, Freshness und Berechtigung ein.

Der berechnete Pfad wird exakt diesem Snapshot, Constraints, Algorithmus-/Policy-Version und Approval zugeordnet. Danach folgen Southbound Request, Geräteannahme, Label/FIB und positive wie negative Paket-Canaries. API-Erfolg ist keine Installation; Installation ist kein Paketbeweis.

Last isolieren und Wissen schützen

Link-State-Änderungen können häufiger sein als gewöhnliche BGP-Prefix-Updates. RFC 9552 empfiehlt dedizierte Route Reflectors oder vergleichbare Isolation und begrenzt die Verteilung auf eine Administrative Domain.

Topologie und TE-Daten bleiben sensibel. Peering gehört nur zu vertrauenswürdigen Speakern; Consumer-only Peers dürfen keine UPDATEs senden. Cisco IOS XR, IOS XE und Juniper dokumentieren reale Controls für Instance, Policy, Queue, Tabellen und Controller-Anbindung. Syntax und Defaults bleiben release-spezifisch und müssen mit Live-State belegt werden.

Sources