Summary

  • „Aktiv“ bedeutet in der SR-Policy-Architektur, dass der Headend den besten gültigen Kandidaten gewählt hat. Es bedeutet nicht, dass ein bestimmter Flow die Steering-Bedingung erfüllte.
  • Eine belastbare Beweiskette verbindet Policy-Identität und gewählten Kandidaten mit Segmentliste, BSID/FIB, Traffic-Selektor, Paketkodierung, beobachtetem Pfad und gemessenem Dienstziel.
  • Beim beschriebenen BGP-Standardverhalten kann eine Route ohne autorisierte Farbe oder passende gültige Policy per IGP aufgelöst werden, obwohl am Headend eine andere Policy aktiv ist.

Der grüne Status, der den Flow nicht bewegte

Man stelle sich eine Latenzanalyse vor. Der Controller zeigt die vorgesehene SR Policy als gültig und aktiv. Der Kandidat mit der höchsten Präferenz ist vorhanden, seine Segmentliste wirkt schlüssig. Trotzdem folgt ein Probe-Paket vom betroffenen Ingress dem normalen IGP-Kürzestpfad.

Beides kann stimmen. Die Policy-Anzeige beantwortet, welcher gültige Kandidat für diese Policy an diesem Headend gewonnen hat. Das Probe-Paket beantwortet, welche Anweisungen dieses Paket tatsächlich erhielt und wohin sie es führten. Erfüllt die Route die Zuordnung aus autorisierter Farbe und Next Hop nicht, kann sie die Steering-Regel verfehlen und ihre IGP-Auflösung behalten. Die Policy bleibt aktiv, trägt aber nicht den untersuchten Verkehr.

„Aktiv“ wirkt wie ein Endpunkt, weil es kurz, maschinenlesbar und meist grün ist. In der Kausalkette steht es jedoch nahe am Anfang.

Was der aktive Zustand tatsächlich belegt

RFC 9256 identifiziert eine SR Policy durch <Headend, Color, Endpoint>; an einem bestimmten Headend reicht <Color, Endpoint>. Eine Policy kann mehrere Kandidatenpfade besitzen. Ein Kandidat ist nutzbar, wenn er gültig ist; aktiv wird der beste gültige Kandidat, primär nach Preference. Relevante Zustandsänderungen lösen die Auswahl erneut aus.

Das ist wertvolle Evidenz: Sie bestimmt das untersuchte Objekt und seinen aktuellen Repräsentanten, einschließlich einer oder mehrerer aktiver Segmentlisten und ihrer Gewichte. Sie belegt nicht, dass der Zielverkehr auf die Policy gesteuert wurde. RFC 9256 knüpft die Nutzung des aktiven Kandidaten an Verkehr, der tatsächlich auf die Policy gelenkt wurde, vorbehaltlich definierter Schutzmechanismen.

Sind mehrere Segmentlisten aktiv, kann die Verteilung gewichtet pro Flow erfolgen; ihre Genauigkeit ist implementierungsabhängig. Eine erfolgreiche Sonde zertifiziert daher nicht die gesamte Verteilung. Eine unerwartete Sonde beweist ebenso wenig, dass alle Flows die Policy verfehlten.

Steering ist eine eigene Entscheidung

Beim BGP-Ziel-Steering verbindet das in RFC 9256 beschriebene Standardverhalten den Next Hop der Route, eine autorisierte Color Extended Community und eine gültige SR Policy, die zu Next Hop und Farbe passt. Bei Übereinstimmung kann die Route über die Policy aufgelöst werden. Fehlt sie, erfolgt standardmäßig die gewöhnliche IGP-Auflösung zum Next Hop.

Ein Dashboard kann verschiedene Zustände in eine beruhigende Zeile pressen. Die Policy kann aktiv sein, während der Route die Farbe fehlt; die Farbe kann vorhanden, aber nicht autorisiert sein; der aus dem Next Hop abgeleitete Endpoint kann abweichen; die passende Policy kann ungültig geworden sein. Eine Umgebung kann außerdem Drop-on-invalid statt IGP-Fallback verlangen. Das sind Steering- und Auflösungsfakten, keine Kandidatenauswahl.

Auch der Binding SID ist keine dauerhafte Identität. Der BSID gehört zum aktiven Kandidaten und stellt eine Forwarding-Anweisung in die Policy dar. Seine Verfügbarkeit muss geprüft werden, Konflikte verlangen einen Alarm, und seine Zuordnung kann sich während der Lebensdauer der Policy ändern. RFC 9256 untersagt deshalb, die Policy über den BSID zu identifizieren. Stabil bleibt das Policy-Tupel; der BSID ist zu prüfender aktueller Forwarding-Zustand.

Die entscheidenden Anweisungen stehen im Paket

RFC 8402 beschreibt Segment Routing als geordnete, am Headend aufgebrachte Anweisungen. Bei SR-MPLS sind es Label in einem Stack, bei SRv6 eine geordnete SID-Liste, häufig in einem SRH. Entspricht das lokale aktive Segment einem Policy-BSID, wird das Paket in die zugehörige Policy gesteuert.

Damit liefert das Paket Belege, die kein Control-Plane-Status ersetzt. Eine Erfassung zeigt, ob die erwarteten Label oder SIDs aufgebracht wurden. Zähler zeigen, ob die programmierte Aktion genutzt wurde. Pfadsonden beobachten den Weg, Latenz- und Verlustmessungen prüfen im selben Zeitraum das Dienstziel. Erst zusammen schließen diese Beobachtungen die Lücke zwischen ausgewählter Absicht und geliefertem Verhalten.

Schutzmechanismen schaffen eine zeitliche Ausnahme. TI-LFA kann beteiligte IGP-Segmente schützen; während der schnellen Umleitung muss der Reparaturpfad nicht alle exakten Policy-Bedingungen erfüllen. Eine aktive Policy und ein kurzzeitig abweichender Pfad können zugleich legitim sein. Zeit und Schutzstatus gehören deshalb in den Vorfallsnachweis.

Quellen