Zusammenfassung

  • Revision 13 lässt die Auswahl der Data Plane einer Policy über und sieht diese pro Neighbor, pro SAFI oder kombiniert vor; dieselbe Adresse kann dadurch in verschiedenen Kontexten anders qualifiziert werden.
  • Der BGP-Update trägt die lokale Auswahl von Plane, Tabelle und OAM-Verfahren nicht mit. Andere Speaker sehen die Entscheidung, aber nicht ihre Ursache.
  • Policy-Version, Match-Kriterien, Tabelle, Forwarding-Generation, Prüfergebnis und betroffene Pfade müssen gemeinsam protokolliert und reversibel sein.

Ein Provider Edge erhielt zwei identische Reachability-Informationen für denselben entfernten Next Hop. Für den VPNv4-Nachbarn wählte die lokale Policy MPLS und verlangte einen funktionierenden LSP. Für einen anderen SAFI-Kontext wählte sie IP-over-Tunnel und prüfte eine andere Forwarding-Tabelle. Der erste Pfad wurde ausgeschlossen, der zweite blieb Kandidat.

Die Adresse war dieselbe. Die Bedeutung von „erreichbar“ kam aus der Konfiguration.

draft-ietf-idr-bgp-bestpath-selection-criteria-13 macht diese Abhängigkeit sichtbar, ohne sie schon vollständig zu regeln. Die Version vom 14. September 2026 ist ein aktiver Internet-Draft der IDR Working Group, für Proposed Standard vorgesehen und als Aktualisierung von RFC 4271 angekündigt, falls sie angenommen wird. Sie ist noch kein RFC. Datatracker verlangt nach der Lösung von Review-Fragen eine Überarbeitung. Routing bewertet den Text als nicht bereit, Operations und Security sehen Probleme, die BGP Directorate erkennt den richtigen Ansatz, aber noch keine Publikationsreife.

Das Grundproblem ist überzeugend. RFC 4271 verlangt vor Phase 2 der Entscheidung, dass eine Route resolvable ist. In einem MPLS-VPN kann der IP-RIB den Next Hop weiterhin finden, während der tatsächlich verwendete LSP nicht forwardet. Ein PE zieht Traffic an und verliert ihn im Kern, weil Control-Plane-Reachability als Ersatz für die gewählte Data Plane dient.

Revision 13 schlägt deshalb vor, die Next-Hop-Reachability im Forwarding Database eines durch Policy ausgewählten Data-Plane-Protokolls zu prüfen. Zusätzlich darf ein Path-Availability-Check mit einem OAM-Liveness-Mechanismus derselben Plane erfolgen. Auswahl von Plane und Mechanismus bleiben außerhalb des Dokuments. Die Policy könne pro Neighbor, pro SAFI oder nach beiden Dimensionen existieren.

Diese Flexibilität entspricht realen Netzen. Sie bedeutet aber auch, dass ein BGP-Pfad keine einheitliche lokale Wahrheit besitzt. Er ist unter einer konkreten Policy-Version, für einen konkreten Peer und eine konkrete Address Family entweder eligible, ineligible oder ungeklärt.

Policy-Provenienz gehört zum Route-Record

Ein übliches BGP-Protokoll zeigt empfangene Attribute, ausgewählten Best Path und gesendete Updates. Es zeigt nicht zwingend, welche Regel die Data Plane auswählte, welchen Table-Lookup sie auslöste und welches OAM-Ergebnis danach die Kandidatur änderte. Ein externer Peer erhält diese lokale Begründung ebenfalls nicht.

Wenn eine Regel geändert wird, können große Pfadmengen ihre Bedeutung wechseln, obwohl kein Nachbar ein neues Update gesendet hat. Eine per-SAFI-Regel kann MPLS aktivieren, eine per-Neighbor-Regel IP bevorzugen; Priorität und Match-Reihenfolge entscheiden. Ein Default nach Software-Upgrade kann dasselbe bewirken.

Ein belastbarer Decision Receipt muss deshalb mindestens enthalten: Prefix und Path-ID; Neighbor; AFI/SAFI; VRF oder Routing-Instanz; ausgewählte Plane; genaue Tabelle; rekursiver Endpoint; Rule-ID und Policy-Version; Match-Ergebnis und Priorität; Forwarding-Generation; OAM-Methode; Ergebnis und Alter; finale Eligibility; sowie den ausgelösten Rechen- und Update-Schritt.

Das ist Daniel Kades Betriebsempfehlung, keine in Revision 13 bereits normierte Datenstruktur. Sie folgt aus einem einfachen Grund: Wer Konfiguration zur Voraussetzung einer Route macht, muss die angewandte Konfiguration zusammen mit der Route beweisen können.

Unterschiedliche Regeln erzeugen unterschiedliche Kandidatenmengen

Die Operations- und Routing-Reviews fragen, welche Tabelle gemeint ist, wenn Zieladresse und Tunnel-Endpoint in verschiedenen Tabellen aufgelöst werden. Revision 13 sagt nur „a forwarding database of a particular data plane protocol“. In VRFs, Multi-Instance-Systemen und rekursiven Tunneln reicht das nicht zur eindeutigen Implementierung.

Zwei Hersteller können dieselbe Policy-Bezeichnung verschieden auf Tabellen abbilden. Zwei Geräte desselben Herstellers können nach einem Upgrade unterschiedliche Defaults verwenden. Ein Teil-Rollout kann auf einem Speaker den erweiterten Check aktivieren und auf einem anderen nicht. Die resultierende Divergenz wird anschließend als BGP-Auswahl exportiert, obwohl ihr Ursprung lokal bleibt.

Hinzu kommt der überholte normative Kontext. Der Draft verweist auf RFC 5512, obwohl RFC 9012 ihn ersetzt und selbst die Resolvability für Tunnel Encapsulation beeinflusst. Reviews nennen SR Policy und neuere Colored-Resolution-Arbeiten. Eine Policy muss daher nicht nur sagen, welche Plane sie will, sondern auch, welche Auflösungsmechanismen Vorrang haben und wie Konflikte behandelt werden.

Ein Name wie prefer-mpls ist kein Beweis. Die gespeicherte, gehashte oder anderweitig unverwechselbare Policy-Version ist es. Ohne sie kann ein späterer Analyst die Entscheidung mit dem aktuellen Regelwerk reproduzieren und trotzdem zu einem anderen Ergebnis kommen.

OAM macht die Policy zeitabhängig

Der optionale zweite Check bringt eine Messung in die Regel. Sie kann on demand stattfinden oder bereits vorher vorliegen. Damit hängt die Auswertung nicht nur von Konfiguration, sondern von Zeitpunkt, Gültigkeitsfenster und Zustand des Messsystems ab.

Ein negatives Ergebnis kann einen tatsächlich defekten MPLS-Pfad sichtbar machen. Es kann aber auch false negative sein, weil das OAM-Verfahren gestört, überlastet, falsch authentifiziert oder noch nicht initialisiert ist. Security weist darauf hin, dass Drop, Delay oder Spoofing der Liveness-Pakete zu Withdrawals, Route Flapping oder Traffic Steering führen kann. Ein spoofed positive kann den ursprünglich gefürchteten Blackhole erhalten.

BFD und LSP Ping sind Beispiele aus den Reviews und den zugehörigen RFCs; Revision 13 schreibt keines vor. RFC 5880 behandelt falsche Up/Down-Deklarationen. RFC 8029 beschreibt Angriffe auf LSP-Ping-Nachrichten. Selbst authentisierte Probes können on path verworfen werden oder einen anderen Fate als Production Traffic erleben.

Die Policy benötigt daher einen expliziten Umgang mit indeterminate: Mechanismus nicht verfügbar, Ergebnis abgelaufen, Forwarding-Generation geändert, Tabellenkontext widersprüchlich oder Beweissignale uneinig. Wer all das als down behandelt, verleiht der Messinfrastruktur eine größere Ausschlussmacht, als ihre Evidenz trägt.

Lokale Gültigkeit ist kein Serviceergebnis

Eine vorhandene Forwarding Entry bestätigt lokalen Zustand. Ein OAM-Erfolg bestätigt eine Antwort innerhalb seiner Methodik. Ein BGP Best Path bestätigt eine Auswahl. Keiner dieser Belege zeigt allein, dass alle ECMP-Member, FECs, entfernten VRFs, Rückwege und Anwendungen funktionieren.

Die Kette bleibt getrennt: Route empfangen; Policy matchen; Plane und Tabelle wählen; Forwarding State lesen; OAM ausführen; Ergebnis klassifizieren; Decision Process neu starten; FIB ändern; Update senden; Peer verarbeiten lassen; Traffic beobachten; Anwendungsergebnis bestätigen. Ein grünes Signal am Anfang ersetzt nicht die Receipts der späteren Schritte.

Das gilt ebenso für negative Aussagen. Ein Withdrawal beweist, dass Control Plane gehandelt hat, nicht dass der ausgeschlossene Pfad defekt war. Ohne Decision Receipt kann ein Review nur das Ergebnis der Policy sehen, nicht ihre Richtigkeit.

Änderung und Rücknahme müssen dieselbe Granularität haben

Eine sichere Einführung beginnt im Shadow Mode. Das System berechnet die neue Eligibility, verändert die Kandidatenmenge aber nicht. Betreiber vergleichen Abweichungen pro Peer, SAFI, VRF, Next Hop und Policy-Version. Sie prüfen sie gegen Forwarding Counters, unabhängige Probes und Application Outcomes.

Die Durchsetzung beginnt in einem begrenzten Kontext mit bekanntem Ersatzpfad. Change Approval nennt die exakte Rule-ID und den erwarteten Route-Radius. Stop-Kriterien umfassen false negatives, uneinheitliche Tabellenwahl, unerwarteten Fan-out und Oszillation. Mixed Deployments bleiben sichtbar, statt als vorübergehender Nebeneffekt ignoriert zu werden.

Rollback stellt die frühere Policy-Version wieder her, invalidiert abgeleitete Zustände und stößt für betroffene Pfade eine kontrollierte Neuberechnung an. Nur den OAM-Prozess zu stoppen reicht nicht, wenn sein letztes Ergebnis weiterhin als Eligibility-Markierung wirkt.

Revision 13 korrigiert eine gefährliche Verkürzung: IP-Reachability ist nicht automatisch MPLS-Forwarding. Ihre offene Governance-Frage ist ebenso wichtig: Eine lokale Policy darf nicht unsichtbar definieren, welche Realität BGP nach außen trägt. Konfiguration wird zur Route-Semantik, sobald sie Kandidaten erzeugt oder vernichtet. Dann verdient sie dieselbe Provenienz wie das Update selbst.

Quellen