Zusammenfassung

  • Beim Sparse Peering nach RFC 9815 sind physischer Forwarding-Graph und BGP-Verteilgraph bewusst verschieden. Der Zustand einer Reflector-Sitzung ist deshalb kein Liveness-Nachweis für die von ihr beschriebenen Fabric-Links.
  • Vor der SPF-Nutzung stehen getrennte Belege: lokaler Detektor, berechtigter Ursprung, Sequenz und Status, gegebenenfalls EoR, passende Gegenrichtung, gültige Deskriptoren und Metriken; danach folgen Berechnung, Installation und Datenebenenmessung.
  • Wer die Kopie mit dem Zeugen verwechselt, konzentriert Autorität an der falschen Stelle. Der betriebliche Gewinn weniger Sitzungen ist nur tragfähig, wenn die gesamte Kette rekonstruierbar bleibt.

Der unsichtbare Fehler im grünen Kontrollraum

Der Route Reflector meldet Established. Die Sitzung ist mit TCP-AO geschützt. Im Adj-RIB-In liegt die Link NLRI mit der höchsten Sequenznummer. SPF wurde ausgeführt, und die Route steht im RIB. Trotzdem verwirft eine Richtung des Leaf-Spine-Links Pakete.

Diese Aussagen widersprechen einander nicht. Established beschreibt die Erreichbarkeit zweier BGP-Endpunkte über den Transportweg ihrer Sitzung. TCP-AO stärkt die Zuordnung zum Sitzungspartner. Die Sequenznummer ordnet Versionen. SPF berechnet aus dem zugelassenen Modell; das RIB zeigt die daraus entstandene Absicht. Keine dieser Anzeigen ist eine Messung der betroffenen physischen Richtung.

Der im Juli 2025 als Standards Track veröffentlichte RFC 9815 definiert BGP-LS-SPF mit SAFI 80. Node-, Link- und Prefix-NLRIs werden über BGP verteilt, während ein SPF-Verfahren die passende Entscheidungslogik übernimmt. Der begleitende RFC 9816 erklärt, wie eine Clos-Fabric mit wenigen Reflector- oder Controller-Sitzungen statt mit einer Sitzung pro physischer Verbindung betrieben werden kann.

In einem dichten Single-Hop-Modell liegen Sitzungs- und Fabric-Graph nahe beieinander. Bei Loopback-Sitzungen oder Sparse Peering lösen sie sich voneinander. Eine Multihop-Sitzung zu einem Controller kann viele Links beschreiben, ohne einen davon als Datenpfad zu benutzen. Deshalb liegen Discovery und Liveness in diesen Modellen außerhalb von BGP; RFC 9815 empfiehlt BFD.

Auch BFD ist nur ein Beleg mit Geltungsbereich. Eine Sitzung muss einer konkreten Schnittstelle oder einem Pfad, einer Adressfamilie und einer Rückrichtung zugeordnet sein. Besonders bei parallelen Links darf ein positives Ergebnis nicht auf Nachbarkanten übertragen werden. Die erste Betriebsanforderung lautet daher: zwei Graphen führen und ihre Verbindung dokumentieren — physische Kante, Detektor, berechtigter Originator, Verteilpfad, konsumierende Router und Datenebenentest.

Neu ist nicht gleich wahr

Eine Link NLRI ist eine gerichtete Behauptung ihres lokalen Knotens. Die Gegenseite erzeugt eine eigene Behauptung für die umgekehrte Richtung. Ein Reflector kann beide Nachrichten tragen; aus dieser Rolle entsteht keine Beobachterstellung.

Jede BGP-LS-SPF-NLRI enthält eine verpflichtende 64-Bit-Sequenznummer. Sie steigt bei selbst erzeugten Änderungen und soll einen Kaltstart über verfügbare Mechanismen überleben. Empfänger bevorzugen grundsätzlich die höhere Nummer; besondere Regeln erlauben direkt verbundenen Peers, veralteten selbst erzeugten Zustand nach einem Neustart zu ersetzen.

Damit wird Replikation geordnet. Ob der Detektor die richtige Schnittstelle beobachtete, wird nicht geprüft. Ein Konfigurationsfehler oder ein kompromittierter, aber berechtigter Peer kann eine brandneue Falschaussage erzeugen. Der Auditdatensatz braucht deshalb Originator, Link-Deskriptoren, Inhalts- und Attribut-Fingerprints, Sequenz, SPF-Status, Empfangspfad und Auswahlgrund. Derselbe NLRI aus mehreren Ursprüngen ist kein Mehrheitsbeweis; der RFC nennt Fehlkonfiguration oder Maskerade als mögliche Ursache.

Beim Linkausfall soll der Originator zunächst eine neuere NLRI mit dem Status „unreachable“ verbreiten und sie erst nach LinkStatusDownAdvertise zurückziehen. Der empfohlene Standardwert beträgt zwei Sekunden. Kehrt der Link währenddessen zurück, entfernt eine nochmals höhere Sequenz den Down-Status. Der neue negative Zustand kann damit alte positive Kopien schlagen, bevor alle Pfade sie zurückgezogen haben.

Aus zwei Sekunden folgt keine Wiederherstellungszusage. Benötigt werden Zeitpunkte für Erkennung, Origination, Empfang an jedem Verbraucher, SPF-Planung und -Ausführung, RIB/FIB-Änderung und erfolgreiche Probes. Erst diese Kette macht Konvergenz messbar.

EoR bestätigt Vollständigkeit, nicht den Link

RFC 9815 erlaubt, die Veröffentlichung der zu einem Peer gehörenden Link NLRI vom End-of-RIB-Marker abhängig zu machen. Unterstützt eine Implementierung diese Einstellung, muss sie im Gebiet konsistent sein. Im aktivierten Zustand wird standardmäßig unbegrenzt gewartet; ein Maximum kann lokal gesetzt werden.

Die Barriere schützt vor einem Router, der Verkehr erhält, bevor seine initiale RIB-Übertragung abgeschlossen und seine Weiterleitung bereit ist. Im Controller-Beispiel kann die Freigabe sowohl EoR als auch Link NLRIs von beiden Endpunkten abwarten. Das ist eine starke Inbetriebnahmeregel, aber kein Pulstest des Kabels. EoR besagt, dass der initiale Transfer einer Adressfamilie unter einer Sitzung ein Ende erreicht hat.

Uneinheitliche Regeln können transiente Microloops und Verluste erzeugen. Ein gemeinsames Feld „ready“ ist darum zu grob. Sitzung etabliert, Adressfamilie ausgehandelt, EoR erhalten, Detektor positiv, lokale und entfernte Link NLRI aktuell, reziproke Zuordnung akzeptiert, Route installiert und Forwarding geprüft müssen einzeln sichtbar bleiben.

Nur die richtige Gegenrichtung schließt die Kante

Der SPF-Prozess übernimmt keinen einseitigen Pfeil. Zu einer aktuellen Link NLRI wird beim entfernten Knoten eine Link NLRI gesucht, die zurückweist. Nummerierte Links werden über gekreuzte lokale Interface- und entfernte Neighbor-Adressen verbunden.

Bei unnummerierten Links dienen Local/Remote Identifier und der Address Family Link Descriptor als Identität. Ohne Adressfamilien-Deskriptor bleibt der Link sowohl aus IPv4- als auch IPv6-SPF ausgeschlossen. Ist die Remote-ID unbekannt, darf null als Wildcard dienen. Bei mehreren parallelen unnummerierten Links kann dadurch vorübergehend unklar sein, ob beide Seiten dieselbe physische Verbindung meinen. Der Management-Abschnitt empfiehlt deshalb, Remote-IDs zu entdecken oder zu konfigurieren.

Die verifizierte Errata 8835 korrigiert genau die reziproke Bedingung. Der veröffentlichte Satz wiederholte denselben Vergleich; korrekt müssen Current Remote und Remote Local sowie Current Local und Remote Remote übereinstimmen. Die Inline-Errata-Fassung zeigt die Korrektur im Lesetext.

Die Errata beweist weder einen Herstellerfehler noch einen Ausfall. Sie zeigt den engeren Nachweisbedarf: Bei parallelen Kanten genügt „beide Knoten stimmen zu“ nicht; beide müssen dasselbe gerichtete Paar meinen. Errata 8836 ist anders gelagert und berichtigt den Namen des RFC-8405-Timers zu TIME_TO_LEARN_INTERVAL. Eine bloße Fehleranzahl würde Identitätslogik und Terminologie irreführend gleichsetzen.

Verbreitet, aber für SPF gesperrt

Auch die Fehlerbehandlung trennt Transport von Berechnung. Eine NLRI ohne BGP-LS Attribute kann nach Attribute-Discard erhalten und weitergereicht werden, darf aber nicht für den SPF-Lookup zurückgegeben werden. Ungültiger Status oder Adressfamilien-Deskriptor wird als Withdraw behandelt. Wer nur empfangene NLRIs zählt, überschätzt deshalb möglicherweise den tatsächlich berechenbaren Graphen.

Geraten die Link-State-Datenbanken zweier Sprecher auseinander, verlangt RFC 9815 einen Sitzungsreset, sofern kein anderes, außerhalb des Dokuments liegendes Resynchronisationsverfahren existiert. Die Benachrichtigung ist definiert; wie das Produkt die Abweichung erkennt, bleibt offen. Ein standardisierter Eingriff beginnt erst nach einem lokalen Nachweis.

TCP-AO reduziert Peer-Maskerade, nicht die Macht eines kompromittierten autorisierten Peers. Dieser kann Node-, Link- oder Prefix-NLRIs verändern, falsche Ursprünge erzeugen oder übermäßige SPF-Arbeit auslösen. Die Identität des Kuriers beglaubigt nicht dessen Bericht über die Leitung.

Der minimale belastbare Versuch

Ein Testnetz sollte den Fabric- und Verteilgraph absichtlich entkoppeln und mindestens ein paralleles unnummeriertes Linkpaar enthalten. Die Baseline dokumentiert beide Richtungen, EoR, reziproke Zuordnung, gleiche LSDB-Fingerprints und Probes über jedes vorgesehene ECMP-Mitglied.

Dann fällt nur eine Richtung aus, während die Reflector-Sitzung bestehen bleibt. Gemessen wird, welcher Detektor zuerst umschlägt, ob ausschließlich der berechtigte Knoten die richtige NLRI erhöht, ob der Down-Status alte positive Kopien überholt, ob die Gegenrichtung die SPF-Zulassung verliert und ob der Next Hop aus dem FIB verschwindet. Bei der Wiederkehr muss eine noch neuere Version den Status heilen, ohne eine alte Identität wiederzubeleben.

Weitere Fälle sind fehlender Adressfamilien-Deskriptor, vertauschte Kennungen, Wildcard bei Parallelität, widersprüchliche Metriken, verzögertes EoR, verworfenes Attribut, verlorener Sequenzstand nach Kaltstart, Doppelursprung, LSDB-Desynchronisation und Reflector-Ausfall. Unterschiedliche Filter gehören dazu, weil RFC 9816 vor divergierenden Tabellen, Unerreichbarkeit und Schleifen warnt.

Das Ergebnis je Fall ist ein verknüpfbarer Belegsatz: Kantenidentität, Detektorbindung, Rohzeit, Ursprung, Deskriptor- und Attribut-Hash, Sequenz und Status, sendender und empfangender Peer, EoR, Zulassungsgrund, LSDB-Generation, SPF-Zeitpunkte, RIB/FIB-Diff, Probes, Alarm, Entscheidung und Rollback.

Das entspricht der Primatstellung des laufenden Codes: Spezifikation, Konfiguration, ausgeführter Übergang und beobachtete Wirkung sind eigenständige Realitätsschichten. Keine darf ohne Beleg die Autorität der nächsten übernehmen.

Was nicht belegt ist

Die Quellen nennen keinen Betreiber-Rollout, keine vollständige Implementierungsmatrix, keine Herstellerdefaults, keine gemessene Konvergenzverteilung und keinen nachgewiesenen Rückgang von Ausfällen. Aussagen zur Effizienz in RFC 9816 sind Architektur- und Anwendbarkeitsargumente, keine Benchmarks.

Sparse Peering ist auch nicht generell überlegen. Sein Wert hängt von Redundanz, Controller-Erreichbarkeit, Detektorbindung, konsistenter Policy, Implementierungsqualität und Diagnosefähigkeit ab. Mehrere Parameter und Einsatzmodelle bleiben bewusst lokal.

Das folgt dem Gedanken einer minimalen Anfangsspezifikation: gemeinsame Identitäten, Ordnung, Status, reziproke Zulassung und Fehlerverhalten; lokale Freiheit bei Topologie und Betrieb. Diese Freiheit erzeugt eine lokale Beweispflicht.

Quellen

  1. RFC-9815-Eintrag im Datatracker
  2. Versionsgeschichte von RFC 9815
  3. Referenzen von RFC 9815
  4. RFC 9815 zitierende Dokumente
  5. RFC-Editor-Infoseite zu RFC 9815
  6. RFC 9815: BGP-LS SPF Routing
  7. Errata zu RFC 9815
  8. RFC 9815 mit Inline-Errata
  9. RFC-Editor-Infoseite zu RFC 9816
  10. RFC 9816: Einsatz und Anwendbarkeit
  11. RFC 4271: BGP-4
  12. RFC 9552: BGP-LS
  13. RFC 5880: BFD
  14. RFC 4724: Graceful Restart und EoR
  15. RFC 8405: SPF-Back-off
  16. RFC 7606: UPDATE-Fehlerbehandlung
  17. RFC 5925: TCP-AO
  18. Heng Lu: Running-Code Primacy
  19. Heng Lu: Minimum Initial Specification
  20. Heng Lu: Reality Layers