6. Operation (Betrieb)

Wenn ein RR eine Route von einem IBGP-Peer empfängt, wählt er den besten Pfad basierend auf seiner Pfadauswahlregel aus. Nachdem der beste Pfad ausgewählt wurde, muss er je nach Art des Peers, von dem er den besten Pfad empfängt, Folgendes tun:

Reflektieren an alle Non-Client-Peers und auch an die Client-Peers. (Daher müssen die Client-Peers nicht vollständig vermascht sein.)

Ein autonomes System könnte viele RRs haben. Ein RR behandelt andere RRs genau wie jeden anderen internen BGP-Speaker. Ein RR könnte so konfiguriert werden, dass er andere RRs in einer Client-Gruppe oder Non-Client-Gruppe hat.

In einer einfachen Konfiguration könnte das Backbone in viele Cluster unterteilt werden. Jeder RR würde mit anderen RRs als Non-Client-Peers konfiguriert werden (somit werden alle RRs vollständig vermascht sein). Die Clients werden so konfiguriert, dass sie die IBGP-Sitzung nur mit dem RR in ihrem Cluster aufrechterhalten. Aufgrund der Routenreflexion erhalten alle IBGP-Speaker reflektierte Routing-Informationen.

Es ist in einem autonomen System möglich, BGP-Speaker zu haben, die das Konzept der Route Reflectors nicht verstehen (nennen wir sie konventionelle BGP-Speaker). Das Route-Reflector-Schema ermöglicht die Koexistenz solcher konventionellen BGP-Speaker. Konventionelle BGP-Speaker könnten Mitglieder entweder einer Non-Client-Gruppe oder einer Client-Gruppe sein. Dies ermöglicht eine einfache und schrittweise Migration vom aktuellen IBGP-Modell zum Route-Reflection-Modell. Man könnte mit der Erstellung von Clustern beginnen, indem man einen einzelnen Router als designierten RR konfiguriert und andere RRs und deren Clients als normale IBGP-Peers konfiguriert. Zusätzliche Cluster können schrittweise erstellt werden.