Zusammenfassung

  • RFC 9815 definiert SPF-Status 2 als Nicht-Transit-Zustand: Der Knoten und seine Präfixe bleiben erreichbar, doch seine ausgehenden Link-NLRIs werden bei der SPF-Erweiterung nicht für Transit weiterverfolgt. Verschwindet die Statusangabe später, wird die frühere Einschränkung implizit zurückgenommen; damit kehrt die Standard-Eignung für Transit zurück, nicht zwangsläufig eine tatsächlich genutzte Transitrolle.
  • Ein erfolgreicher Erreichbarkeitstest nach einem Kaltneustart beweist daher nicht, dass die zuvor gewünschte Nicht-Transit-Bedingung erhalten blieb. Für eine belastbare Abnahme müssen positive Erreichbarkeit und die negative Einschränkung „nicht als Transit verwenden“ als getrennte Aussagen mit getrennten Nachweisen behandelt werden.

Sollzustand und Istzustand sind zwei verschiedene Aussagen

Der Sollzustand vor dem Neustart sei eindeutig: Der Knoten soll für seine eigenen Dienste und Präfixe erreichbar bleiben, aber nicht als Transitknoten dienen. Dafür wurde im Node SPF Status TLV der Wert 2 signalisiert. Nach dem Kaltneustart zeigt der Istzustand nur noch die erste Hälfte: Der Knoten ist erreichbar. Die explizite Nicht-Transit-Angabe fehlt.

Nach RFC 9815, Abschnitt 5.2.1.1 ist das Node SPF Status TLV vom Typ 1184 optional. Sein Fehlen bedeutet, dass der Knoten als „up“ gilt und für Transit verfügbar ist. Wurde zuvor ein Status signalisiert und das TLV später nicht mehr mitgeführt, wird der frühere Status implizit zurückgenommen. Die Basisspezifikation selbst ist als Standards Track veröffentlicht; die RFC-Informationsseite zu RFC 9815 ordnet das Dokument entsprechend ein.

Das ist kein Beweis dafür, dass nun Verkehr durch den Knoten fließt. Es ist zunächst eine Änderung der Berechnungsgrundlage. Die ausdrückliche Sperre gegen Transit ist verschwunden. Ob daraus ein tatsächlich genutzter Pfad entsteht, hängt von den übrigen Eingaben der SPF-Berechnung sowie von dem Zustand ab, der anschließend in die Weiterleitung übernommen wurde.

Gerade deshalb ist „Standard wiederhergestellt“ nicht dasselbe wie „autorisierte Rolle wiederhergestellt“. Der Standardzustand des Protokolls kann korrekt sein und trotzdem vom beabsichtigten Betriebszustand abweichen.

Was Status 2 in der SPF-Berechnung tatsächlich bewirkt

Die Bedeutung von Status 2 wird präziser, wenn man den Algorithmus betrachtet. RFC 9815, Abschnitt 6.3 trennt mehrere Schritte. In Schritt 3 werden Knoten mit Status 1 ignoriert. Schritt 4 berücksichtigt die Präfixe des jeweils erreichbaren aktuellen Knotens. Schritt 5 erweitert anschließend dessen ausgehende Links — außer wenn der aktuelle Knoten Status 2 trägt.

Damit bleibt bei Status 2 ein wichtiger Unterschied erhalten: Der Knoten kann als erreichbar gelten, und seine Präfixe können weiterhin in die Berechnung einfließen, ohne dass der Algorithmus von diesem Knoten aus über seine ausgehenden Link-NLRIs weiter expandiert. Genau daraus entsteht die Nicht-Transit-Wirkung.

Status 1 verfolgt einen anderen Zweck. Er kennzeichnet den Knoten als nicht erreichbar. Status 2 ist dagegen keine Variante von „down“. Er belässt die Erreichbarkeit und beschränkt die Transitverwendung.

Das erklärt auch, warum ein Neustart mit erfolgreichem Dienstetest nicht genügt. Ein Dienst kann korrekt antworten, obwohl der entscheidende negative Steuerwert verschwunden ist. Die positive Aussage „erreichbar“ und die negative Aussage „nicht für Transit expandieren“ sind im Protokoll getrennt kodierbar und sollten operativ ebenso getrennt geprüft werden.

Auslassen heißt Eignung, nicht tatsächliche Nutzung

Die wichtigste Unsicherheitsgrenze liegt zwischen Eignung und realer Pfadnutzung. Wird Status 2 ausgelassen, ist der Knoten gemäß RFC 9815 wieder für Transit verfügbar. Daraus folgt aber nicht, dass SPF ihn zwingend in einen ausgewählten Pfad einbezieht.

Die tatsächliche Auswahl hängt von der sichtbaren Topologie, den relevanten Metriken und der SPF-Berechnung ab. Selbst ein berechneter Pfad sagt noch nicht allein, wie der installierte Weiterleitungszustand für einen bestimmten Verkehrsstrom aussieht. Und selbst aus diesem Zustand lässt sich ohne passende Prüfung nicht pauschal ableiten, welche konkreten Flüsse zu einem bestimmten Zeitpunkt tatsächlich über den Knoten laufen.

Die korrekte Schlussfolgerung ist daher begrenzt: Das Verschwinden von Status 2 entfernt die im SPF-Verfahren definierte Nicht-Transit-Beschränkung. Es stellt Transit-Eignung wieder her. Alles Weitere muss anhand der konkreten Berechnung, Installation und Prüfung belegt werden.

Diese Grenze ist nicht bloß semantische Vorsicht. Sie verhindert zwei gegensätzliche Fehlschlüsse: Einerseits wäre es falsch, aus dem fehlenden Status sofort auf tatsächlichen Transitverkehr zu schließen. Andererseits wäre es ebenso falsch, aus einem erfolgreichen Dienstetest zu schließen, dass die Nicht-Transit-Absicht weiterhin wirksam sei.

Die übrigen Statuswerte begrenzen Interpretationsspielraum

Die registrierten Werte sind eng gefasst. RFC 9815, Abschnitt 8.3 und das dazugehörige IANA-Register für BGP SPF führen für Node SPF Status die Werte 0 als reserviert, 1 als „unreachable“, 2 als „non-transit“, 3 bis 254 als nicht zugewiesen und 255 als reserviert.

Nicht zugewiesene Werte zwischen 3 und 254 werden propagiert, von SPF jedoch ignoriert; eine Implementierung kann sie protokollieren. Die reservierten Werte 0 und 255 haben eine andere Folge: Sie machen die Node NLRI fehlerhaft. Nach RFC 9815, Abschnitt 7.1 greift dafür die dort beschriebene Fehlerbehandlung mit „treat-as-withdraw“.

Auch diese Unterscheidung ist für Betrieb und Governance wichtig. „TLV fehlt“, „Status 2“, „nicht zugewiesener Wert“ und „reservierter ungültiger Wert“ sind keine austauschbaren Zustände. Sie haben unterschiedliche protokollseitige Wirkungen und dürfen in einer Prüfung nicht unter einer allgemeinen Kategorie wie „Status abweichend“ zusammengefasst werden.

Der Codepunkt des TLV selbst ist ebenfalls eindeutig registriert. RFC 9815, Abschnitt 8.2 und das IANA-Register BGP-LS Parameters führen 1184 als SPF Status. Für die Node-Statuswerte ist dagegen das BGP-SPF-Register maßgeblich. Diese Zuordnung ist präziser als ein pauschaler Verweis auf eine allgemeine BGP-Parameterseite.

Die Node NLRI bleibt obligatorisch

RFC 9815 macht die Node NLRI nicht von einer besonderen Rolle abhängig. Jeder BGP-SPF-Router kündigt sie bedingungslos an. Das ist Teil der Grundmechanik des Verfahrens, wie sie in RFC 9815 beschrieben wird.

Der optionale Charakter betrifft das SPF Status TLV, nicht die Node NLRI selbst. Nach einem Neustart kann deshalb ein vollständig sichtbarer Node-Eintrag vorliegen, während die zuvor relevante Einschränkung fehlt. Gerade diese Kombination macht die gewünschte Soll-Ist-Prüfung notwendig: Sichtbarkeit des Knotens ist kein Ersatz für den Nachweis seiner vorgesehenen Transitrolle.

RFC 9816 grenzt die Nicht-Transit-Anwendung bewusst ein

Der Begleittext RFC 9816 beschreibt Nutzung und Anwendbarkeit von BGP-SPF; die RFC-Informationsseite zu RFC 9816 ordnet das Dokument entsprechend ein. Für Status 2 nennt RFC 9816, Abschnitt 7 zwei Anwendungen: einen Anwendungsserver, der erreichbar sein soll, ohne als Router zu fungieren, und einen Controller auf einem Server, der direkt erreichbar sein soll, ohne Transitverkehr zu tragen.

Mehr sollte daraus nicht abgeleitet werden. Diese Beispiele belegen weder eine bestimmte reale Verbreitung noch eine beobachtete Implementierung. Sie definieren Status 2 auch nicht als allgemeines Wartungs- oder Überlastungssignal. Wer solche zusätzlichen Bedeutungen einführt, verlässt den hier eingefrorenen Belegrahmen.

Für die Neustartfrage reicht die Spezifikation dennoch aus: Es existiert eine standardisierte Möglichkeit, Erreichbarkeit und Transitverwendung zu trennen. Wenn die dafür verwendete Angabe nach dem Neustart fehlt, ist die gewünschte Trennung nicht mehr durch genau diesen Mechanismus belegt.

Sichtbarkeit ist nicht gleich Datenpfad-Nachweis

Eine zweite wichtige Grenze stammt nicht aus RFC 9815, sondern aus dem Anwendbarkeitsdokument. RFC 9816, Abschnitt 5.5.2 trennt die Sicht auf die Topologie von optionaler Verifikation des Datenpfads.

Für den Kaltneustart bedeutet das: Ein beobachteter Node-Status oder dessen Fehlen sagt etwas über die Steuerinformation aus. Ob ein bestimmter Datenfluss den Knoten tatsächlich nutzt oder meidet, kann zusätzlich geprüft werden. Ein negativer Test hat dabei nur begrenzte Aussagekraft: Er kann zeigen, dass definierte Flüsse zu definierten Zeitpunkten den unerwünschten Weg nicht genommen haben. Er beweist keine universelle Abwesenheit von Transit über alle möglichen Flüsse und Zeitpunkte.

Gerade für Governance-Verantwortliche ist diese Begrenzung entscheidend. Ein guter Nachweis verspricht nicht mehr, als er messen kann. „Wir haben für diese Flüsse zu diesem Zeitpunkt keinen Transit beobachtet“ ist eine belastbare, begrenzte Aussage. „Der Knoten wird niemals für Transit verwendet“ wäre ohne wesentlich weitergehenden Beleg nicht gerechtfertigt.

Wer besitzt die negative Betriebsabsicht?

Die technische Mechanik führt unmittelbar zu einer Verantwortungsfrage. Ein positiver Zustand ist oft leicht zu erkennen: Der Knoten antwortet, der Dienst ist verfügbar, die Präfixe sind erreichbar. Eine negative Einschränkung verlangt dagegen den Nachweis, dass etwas bewusst nicht zugelassen wird.

Wenn Status 2 vor einem Neustart Teil des gewünschten Zustands war, muss deshalb geklärt sein, wer dafür verantwortlich ist, dass diese Angabe in der Konfiguration, bei der Neuerzeugung des Zustands und nach einer Softwareänderung erhalten bleibt. Die Spezifikation weist diese organisatorische Verantwortung keinem bestimmten Team zu. Sie definiert nur die Protokollwirkung.

Hier hilft eine klare Trennung der Rollen: Ein Dienstverantwortlicher kann Erreichbarkeit bestätigen. Ein Routing-Verantwortlicher kann bestätigen, dass Status 2 wieder vorhanden ist oder dass eine andere ausdrücklich autorisierte Steuerung den gleichen gewünschten Betriebszweck erfüllt. Eine Abnahme sollte diese Aussagen nicht zu einem einzigen grünen Feld verdichten.

Der von Heng Lu formulierte Gegensatz zwischen geschriebenem Willen und tatsächlich laufender Technik kann hier als redaktionelle Linse dienen. In „Running Code Primary“ steht die praktische Prüfung dessen im Vordergrund, was real ausgeführt wird, statt sich allein auf dokumentierte Absicht zu verlassen. Auf BGP-SPF übertragen heißt das nicht, den Text der Spezifikation abzuwerten. Es heißt, die konfigurierte Absicht am tatsächlich signalisierten und geprüften Zustand zu messen.