Zusammenfassung

  • RFC 9107 lässt einen Reflector Interior Cost von einer konfigurierten IGP-Position für Client, Gruppe oder ganzen Reflector berechnen statt von seinem physischen Standort.
  • „Optimal“ bezeichnet die Wahl dieser Perspektive aus denselben zulässigen Kandidaten unter der maßgeblichen Policy; es garantiert weder geringste Latenz noch Kosten oder Stau.
  • Sicherer Betrieb beweist Root-Zuordnung, Topology Epoch, Kandidatenvollständigkeit, Rechenkapazität, Backup, Client-Anzeige und FIB-Ausgang.

Ein virtueller Reflector im Rechenzentrum bedient Router in drei Städten. Zwei Border Router kündigen dasselbe Prefix an. Local Preference, AS_PATH und höhere Kriterien sind gleich; die Entscheidung erreicht den IGP Cost. Für den östlichen Client ist Ausgang Ost näher, für den westlichen Reflector Ausgang West.

Der Reflector beantwortet korrekt: Welcher Next Hop ist mir näher? Er sendet West an alle Clients. Ost sieht seinen anderen Kandidaten nicht. Pakete durchqueren das Backbone zu einem Ausgang, der nur für eine nicht-forwardende Control-Plane-Maschine optimal war.

Kein Einzelteil muss defekt sein. IGP, Decision Process und Session sind korrekt. Falsch ist die Perspektive. Ein exakter Algorithmus aus der falschen Stadt liefert dem Nutzer zuverlässig das falsche Ergebnis.

RFC 4456 kennt diesen Scaling-Preis. Route Reflection fasst Information zusammen und reflektiert gewöhnlich nur den eigenen Best Path. Da IGP-Kosten je Router variieren, liefern manche Topologien nicht dieselbe Wahl wie Full Mesh. Klassisch werden Reflection und Forwarding Topology eng ausgerichtet.

Zentrale und virtuelle Reflectors lockern diese Beziehung. Sie stehen außerhalb des Data Path, wo Compute bequem ist. Ihr IGP-Standort wird zufälliger Traffic-Engineering-Input. Eine vRR-Migration kann Ausgänge ändern, obwohl keine externe Route wechselte.

RFC 9107 ersetzt den Zufall durch einen Logical IGP Root: einen Link-State-Knoten, etwa per Loopback-Adresse. Der Reflector baut von dort einen Shortest-Path Tree und nutzt die Kosten zu BGP Next Hops beim Interior-Cost-Vergleich.

Der Root ist Blickpunkt, kein Waypoint. Pakete müssen ihn nicht durchlaufen. BGP Next Hop, rekursive Auflösung und Client-FIB bestimmen den Pfad. Den Root als Traffic-Hop darzustellen verwechselt Modell und Wirkung.

Granularität kann pro Reflector, Client Group oder Client gewählt werden. Ein konformes Produkt muss mindestens eine Kategorie unterstützen. RFC-Konformität verspricht keine Per-Client-Präzision.

Jede Stufe ist eine Annäherung. Ein Root kostet wenig und kann alte Verzerrung behalten. Eine Region vertritt ihre Mitte besser als ihre Ränder. Per Client ist genauer und vervielfacht SPF und Decision Process. Präzision ist ein Kapazitätsbudget.

Optimal bleibt begrenzt. Basis-ORR ersetzt den IGP Cost in Schritt e von RFC 4271 Phase 2. Frühere Policies bleiben vorrangig. Höhere Local Preference kann einen entfernten Ausgang wählen.

IGP Cost misst nicht automatisch Latenz, Congestion, Loss, Transitpreis oder Wartungsrisiko. ORR unterstützt Hot Potato unter vorheriger Policy. Korrekt ist „nächster zulässiger Ausgang nach dieser Metrik“, nicht „global bester Pfad“.

Brauchen Gruppen verschiedene BGP Policies, kann RFC 9107 größere Teile oder den ganzen Decision Process mehrfach ausführen. Group Assignment delegiert dann Topologie- und Geschäftsperspektive. Ein Gruppenwechsel kann tausende Adj-RIB-Out ändern, ohne IGP Event oder externes UPDATE.

Das Mapping ist Production Policy mit Version, Review, kleiner Kohorte, exaktem Diff und Rollback.

Der Kandidatenbestand muss vollständig sein. Ein Reflector kann keinen ungelernten Weg im Namen des Clients wählen. RFC 9107 verlangt alle zulässigen Pfade und ADD-PATH zwischen Reflectors für clusterübergreifende Vollständigkeit.

Capability allein beweist nichts. Richtung, AFI/SAFI, Sender Set, Import Policy und tatsächliches Adj-RIB-In müssen stimmen. Perfekter SPF auf unvollständiger Menge bleibt falsch.

ORR verteilt State neu. Multiple Paths bis zum Edge erlauben lokale Entscheidung und erhöhen Edge-RIB sowie Updates. ORR hält Kandidaten zentral, rechnet je Perspektive und sendet kleinere Ergebnisse. Verteilte Einsparung konzentriert Information, CPU und Vertrauen.

Topologie benötigt Provenance. RFC 9107 nennt IS-IS, OSPF und BGP-LS. Eine Database kann stale, auf falschen Area/Level begrenzt, ohne Root oder zwischen Reflectors inkonsistent sein. Feed vorhanden bedeutet nicht View korrekt.

BGP-LS transportiert Link State, zertifiziert aber keine Freshness. Erfassen Sie Epoch, Coverage, Source-Session-Health und Vergleich zum IGP der Forwarders. RFC 7752 wurde durch RFC 9552 ersetzt; der aktuelle Stack muss benannt werden.

Rekursive Next Hops bilden eine weitere Grenze. Wird ein BGP Next Hop über BGP aufgelöst, zählt der finale IGP Cost. Kann ein Produkt ihn nicht liefern, muss der Pfad beim Metric-Vergleich least preferred sein, bleibt aber in Phase 2 valid. Eine gültige Route kann wegen fehlender Rekursionssicht verlieren.

Produktgrenzen sind keine RFC-Regeln. Junos dokumentiert MPLS-bezogene Resolution-Einschränkungen; Cisco nennt rSPF, BGP-LU und Multiple IGP Topologies. Jede Plattform und Address Family braucht eigene Prüfung.

Auch ein Vendor-Versprechen von „optimal“ schließt die Kette nicht. Software kann für den falschen Root, alte Topologie oder unvollständige Kandidaten korrekt rechnen. Product Correctness ist nicht System Correctness.

Backup Roots verschieben den Beobachter. RFC 9107 empfiehlt Backup Locations, Junos dokumentiert Primary und Backup. Bei Ausfall bleibt Reachability möglich, während viele Ausgänge wechseln. Der Backup braucht vorhergesagten Route-Set-Diff, SPF- und FIB-Test.

Hop-by-Hop-Netze mit mehreren Reflectors ohne Encapsulation verlangen Loop-Sorgfalt. Eine aus einem Root rationale Wahl kann systemweit gefährlich interagieren.

Compute gehört zum Vertrag. Hunderte Roots bedeuten viele SPF Trees und BGP-Auswertungen über große Tabellen. Feine Granularität kann CPU, Memory, Queue und Convergence gerade im Fehler verschlechtern.

Kapazitätstests kombinieren Routes, Clients, Roots, IGP Nodes und Failure Fan-out. Sie messen Steady State, Full Recalculation, Incremental Change und die Zeit vom IGP Event zur Client-Anzeige. Nur im ruhigen Labor korrekt reicht nicht.

Das erste Artefakt ist ein Perspective Registry mit Client, AFI/SAFI, Primary, Backup, Group, Policy, Owner und akzeptierter Annäherung. Das zweite beweist Kandidaten und ADD-PATH. Das dritte speichert Epoch, Kosten und Winning Step.

Das vierte kommt vom Client: Received Route, Import, Best Reason, Rekursion, FIB und gemessener Egress. Wählt er eine andere Quelle, ist das ein zu erklärender Running Fact.

Tests umfassen Group Move, Root Loss, Backup, Hidden Candidate, Stale Topology, Rekursion, Higher Policy und Compute Saturation. Jedes Szenario braucht Expected Diff und Zeitgrenze.

Rollback stellt Perspektive wieder her. ORR zu entfernen kann zum physischen Reflector-Standort zurückkehren; Reverse Updates müssen aber Client und FIB ändern. Zwischenzeitliche Topologie- oder Kandidatenwechsel verhindern eventuell exakte Rückkehr.

Teilen Sie Authority. IGP Owners prüfen Roots, BGP Owners Groups und Policies, Reflector Operators Kapazität, Traffic Owners Egress. Independent Review muss die Behauptung ablehnen können, ein Root vertrete einen Client.

Heng Lus Minimum Initial Specification passt: ein schmaler Mechanismus aus Logical Point und Decision Stage, während Granularity und Adoption lokal bleiben. Running-Code-Primacy verlangt Topology, Set, Advertisement, FIB und Packet. Datensouveränität heißt, die Entscheidung prüfen und bestreiten zu können.

ORR repariert Zentralisierung durch gezieltere Zentralisierung. Es befreit den Reflector von seiner physischen Stadt und macht die Root Map zur neuen Routing Authority. Nicht das Wort optimal, sondern verwendete Perspektive und beobachtete Pakete schließen die Beweiskette.

Quellen