Zusammenfassung

  • RFC 9983 definiert 0x10 als AC-Flag im OSPFv2 Extended Prefix TLV: Das Präfix ist dazu bestimmt, von mehreren Knoten angekündigt zu werden.
  • Zwischen dieser Absicht und einem erfolgreichen Dienst liegen unabhängig nachzuweisende Schritte: LSA-Verteilung, lokale Route/FIB, Datenpfadauswahl, Replikgesundheit und Anwendungsergebnis.

Ein Operations-Report kann drei saubere Beobachtungen enthalten: dasselbe Präfix wird mehrfach angekündigt, eine Anzeige enthält AC-Flag, und ein BGP-LS-System führt die Eigenschaft ebenfalls. Daraus entsteht rasch der Satz „der Anycast-Dienst ist verfügbar“. Der Satz ist größer als seine Belege.

RFC 9983 wurde im Mai 2026 als IETF Standards Track veröffentlicht und definiert OSPFv2 Anycast Property Advertisement. 0x10 ist das Anycast Flag im Register für Extended-Prefix-TLV-Flags. Seine einzige Semantik lautet, dass das Präfix von mehreren Knoten angekündigt werden soll. Für ein als anycast konfiguriertes Präfix muss das Flag gesetzt werden; für ein anderes muss es gelöscht werden.

Damit beantwortet die Norm eine Frage, die mehrfache Ankündigungen nicht beantworten können. Diese können beabsichtigtes anycast, eine Migration, einen vorübergehenden Topologieeffekt oder eine Fehlkonfiguration ausdrücken. Das Flag trägt eine explizite Absicht durch das Routing-System. Wird eine Extended Prefix Opaque LSA in ein anderes Gebiet neu angekündigt, muss das Flag erhalten bleiben.

Der Erhalt der Absicht ist jedoch kein Nachweis, dass ein Paket eine dienstfähige Instanz erreichte.

Die Beweiskette hat lokale Glieder

Zuerst steht die genehmigte Konfiguration und ihre Management-Identität. Danach steht, welche LSA welcher Router in welchem Area tatsächlich empfing. Dann folgen die lokalen SPF- und Policy-Entscheidungen, die eine Route erzeugen oder eine FIB-Installation verweigern können. Erst auf dem Datenpfad bestimmen ECMP-Hash, Rekursion, Nachbarschaft und Rückweg, welche Replik ein konkreter Fluss erreicht. Schließlich muss diese Replik gesund sein, den passenden Zustand besitzen und die angeforderte Anwendungshandlung abschließen.

Jedes Glied kann gelten, während das nächste scheitert. Eine korrekt markierte LSA kann ein relevantes Area nicht erreichen. Eine RIB-Kandidatin kann durch lokale Policy aus der FIB bleiben. Eine installierte Route kann einzelne Flüsse zu einer drainierten oder überlasteten Instanz führen. Eine TCP-Prüfung kann gelingen, obwohl die authentisierte Anwendungstransaktion fehlschlägt.

RFC 9983 verspricht diese späteren Tatsachen nicht. Er verlangt im Gegenteil, dass Empfänger, die das Flag für Forwarding- oder Sicherheitsentscheidungen nutzen, Konfigurationsfehler und inkonsistente Implementierung bedenken. Das Flag ist daher keine schwache Information; es ist eine Information mit einer klaren Zuständigkeitsgrenze.

Heng Lus Gedanke einer minimalen gemeinsamen Spezifikation hilft, die Grenze nicht zu verwischen. Gemeinsam nötig ist hier die Aussage über einen beabsichtigten Mehrknoten-Präfix. Gesundheitsdefinition, Lastverteilung, Dienstinhaberschaft und fachlicher Erfolg sind lokale Entscheidungen. Sie brauchen lokale Beobachtung und sollten nicht in einem global replizierten Symbol fingiert werden.

Ein Konflikt, den ein Normalisierer nicht verschlucken darf

Das AC-Flag darf nicht zugleich mit dem N-Flag aus RFC 7684 gesetzt sein. Bei beiden Flags muss ein Router eine Konfigurationsanomalie annehmen, das N-Flag ignorieren und den Konflikt, rate-limitiert, protokollieren.

Ein Monitoring-System darf diesen Zustand weder als normales „Prefix-Metadatum gültig“ glätten noch allein als Dienstunterbrechung deuten. Die Norm begründet beides nicht. Die richtige Steuerung isoliert den Konflikt von positiven automatisierten Entscheidungen, ermittelt Konfigurations- und Ankündigungsursprung und bewertet die reale Wirkung aus getrennten Pfad- und Servicebelegen.

Sichtbarkeit ist keine Betriebsautorität

Bei einem mehrfach angekündigten Präfix genügt nach RFC 9983 mindestens eine Ankündigung mit AC-Flag, damit das Präfix als anycast gilt; eine einzelne Ankündigung ohne Flag bleibt knotenspezifisch. Der Text fordert konsistente Verwaltung und strenges Monitoring veralteter Konfigurationen, weil das Flag bei der Eigenschaftszuordnung Vorrang hat.

RFC 9085 ermöglicht, dass BGP-LS die einschlägigen Präfixflags mitführt. Ein Topologie-Collector kann die Aussage deshalb zuverlässig berichten. Er kann daraus nicht ableiten, welche FIB an welchem Ingress aktiv war, welche ECMP-Entscheidung fiel oder ob eine Replik die gewünschte Wirkung erzielte. Drei Ansichten derselben Quelle sind keine drei unabhängigen Zeugen.

Die via RFC 9129 und RFC 8349 ergänzten YANG-Daten machen anycast-flag schreibbar. Damit wird die Verwaltungsschnittstelle zur Kontrollfläche für eine nachgelagerte Behauptung. RFC 9983 verlangt sicheren Management-Transport, gegenseitige Authentisierung und verweist auf NACM zur Zugriffsbeschränkung. Wer das Flag für Forwarding oder Security heranzieht, muss Schreibberechtigung, Review, Versionsstand und Konfliktbehandlung nachweisen können.

Präzise Sprache für präzise Beobachtung

Für jedes kritische Präfix sollten Konfigurationsfreigabe, empfangene LSAs nach Area, AC/N-Konflikte, Routenberechnung/FIB an relevanten Ingresses, Datenpfadauswahl, Replikgesundheit und Anwendungsergebnis verknüpft bleiben. Nicht jeder Alarm muss alle Belege vorweisen. Aber die Behauptung muss die beobachtete Ebene nennen: „AC-Flag gesehen“ ist belastbar; „Anycast-Service gesund“ ist ohne weitere Glieder unbelegt.

Ohne diese Trennung wird nach einem Ausfall die sichtbare Kennzeichnung repariert, während die gescheiterte lokale Entscheidung – Auswahl, Health Admission, Identität oder Anwendungszustand – unsichtbar bleibt.