Zusammenfassung

  • Route Reflection ersetzt den herkömmlichen IBGP-Full-Mesh durch konfigurierte Client- und Non-Client-Beziehungen. Das senkt die Zahl der Sitzungen, macht die Best-Path-Auswahl des Reflectors aber zur Verteilungsgrenze.
  • ORIGINATOR_ID und CLUSTER_LIST helfen, Reflection-Schleifen zu erkennen, authentifizieren jedoch keinen Routenursprung. Redundanz, Topologiekongruenz und Konfigurationsintegrität bleiben Betreiberpflichten.

Die Sitzungszahl wird zur Hierarchie

Im herkömmlichen Modell benötigen n BGP-Knoten innerhalb eines autonomen Systems n*(n-1)/2 einzelne IBGP-Sitzungen. Der Grund ist strukturell: Eine von einem IBGP-Peer gelernte Route wird normalerweise nicht an einen weiteren IBGP-Peer weitergegeben. Jeder Knoten braucht deshalb die direkten internen Verbindungen, über die er externe Routinginformationen erhält.

RFC 4456 lockert diese Regel für einen entsprechend konfigurierten Route Reflector. Seine internen Peers sind Clients oder Non-Clients. Nachdem er seinen besten Pfad gewählt hat, reflektiert er eine von einem Non-Client gelernte Route an alle Clients. Eine von einem Client gelernte Route geht an die anderen Clients und an die Non-Clients. Clients müssen untereinander keinen Full Mesh bilden; für Non-Clients bleibt diese Anforderung bestehen.

Das ist ein echter Skalierungsgewinn. Herkömmliche BGP-Knoten können weiterbestehen, und Cluster lassen sich schrittweise einführen, ohne das autonome System zu ändern. Die Reduktion ist jedoch nicht kostenlos: Der Reflector verteilt nur seinen besten Pfad. Die Sicht eines Clients hängt damit von einer Entscheidung an anderer Stelle ab.

Konfiguration vergibt eine Rolle, keine Routenautorität

Das Protokoll bietet einem Client keine Möglichkeit, sich dynamisch als Client zu identifizieren. RFC 4456 nennt manuelle Konfiguration als einfachste Methode. Diese Beziehung ermächtigt den Reflector, die festgelegten internen Verteilungsregeln anzuwenden. Sie beweist weder den legitimen Ursprung eines Präfixes noch die Berechtigung des externen Nachbarn zur Ankündigung und auch nicht, dass der bevorzugte Pfad allen Clients gleichermaßen dient.

Betriebliche Macht wird gebündelt, bleibt aber begrenzt. Der Reflector wählt nach dem BGP-Entscheidungsprozess seinen besten Pfad und steuert, welche internen Beziehungen ihn erhalten. Edge-Router behalten ihre Import-Policy; der Betreiber verantwortet weiterhin IGP-Design, MED-Behandlung, LOCAL_PREF, Validierung, Kapazität und Störungsreaktion. Große autonome Systeme profitieren von vermiedenem quadratischem Sitzungswachstum und schrittweiser Migration. Die Kosten liegen in Platzierung, Redundanz, Konfigurationsintegrität, Sichtbarkeit und Fehlerdomänen.

Schleifenattribute schützen die Reflection-Topologie

Fehlkonfigurationen können bei Route Reflection Verteilungsschleifen erzeugen. RFC 4456 ergänzt zwei optionale, nicht transitive Attribute. ORIGINATOR_ID hält den BGP Identifier des internen Ursprungs fest. Ein Knoten sollte das Attribut nicht neu erzeugen, wenn es bereits existiert, und sollte eine Route mit der eigenen Kennung ignorieren.

CLUSTER_LIST zeichnet die Reihenfolge der durchlaufenen Cluster auf. Ein Reflector muss seine lokale CLUSTER_ID voranstellen und das Attribut anlegen, wenn es fehlt. Ist die lokale CLUSTER_ID bereits enthalten, sollte die empfangene Ankündigung ignoriert werden. Die normative Abstufung zählt: Anlegen und Voranstellen sind MUST-Anforderungen; das Ignorieren ist eine SHOULD-Empfehlung.

Ein Cluster mit nur einem Reflector hat einen Single Point of Failure. Mehrere Reflectors können eine vier Byte lange CLUSTER_ID teilen, sodass einer eine Route eines anderen Reflectors desselben Clusters verwirft. Redundanz verlangt daher eine konsistente Clusteridentität und ein stimmiges Design, nicht bloß ein zusätzliches Gerät.

Die Auswahl kann vom Full Mesh abweichen

RFC 4456 warnt, dass IGP-Kosten je Router variieren und MED-Werte nicht immer vergleichbar sind. In manchen Reflection-Topologien kann die Auswahl deshalb vom Ergebnis eines vollständigen IBGP-Mesh abweichen. Das Dokument erläutert Möglichkeiten zur Angleichung, erkennt aber an, dass erzwungene Gleichheit einschränkend oder unpraktisch sein kann.

Die stärkere Forderung ist architektonisch: Die Topologie muss sorgfältig betrachtet werden, damit Schleifen vermieden und konsistente Sichten erhalten bleiben. Bei mehreren Pfaden sollte die Reflection-Topologie im Allgemeinen mit der Netzwerktopologie kongruent sein. Ein Reflector sollte NEXT_HOP, AS_PATH, LOCAL_PREF oder MED beim Reflektieren nicht verändern, weil dadurch Schleifen entstehen können.

Belege und Grenzen

RFC 4456 beschreibt das Skalierungsproblem, Client-Regeln, Schleifenattribute, Redundanz und Folgen für die Pfadauswahl. RFC 4271 liefert das zugrunde liegende BGP-Austausch- und Entscheidungsmodell. Aussagen zu Macht, Autorisierung, Nutznießern, Kosten und Verantwortung sind daraus abgeleitete Analyse.

Die Quellen belegen weder das Design eines benannten Netzes noch dessen aktuelle Konfiguration. Sie authentifizieren keinen Ursprung, garantieren keine Gleichheit mit dem Full Mesh und schreiben keine universelle Hierarchie vor. RFC 4456 stellt ausdrücklich fest, dass die Erweiterung die grundlegenden Sicherheitsprobleme von BGP nicht ändert.

Quellen