6. Operation (Opération)

Lorsqu'un RR reçoit une route d'un pair IBGP, il sélectionne le meilleur chemin en fonction de sa règle de sélection de chemin. Une fois le meilleur chemin sélectionné, il doit faire ce qui suit en fonction du type de pair dont il reçoit le meilleur chemin :

Réfléchir à tous les clients.

Réfléchir à tous les pairs non-clients et aussi aux pairs clients. (Par conséquent, les pairs clients ne sont pas tenus d'être entièrement maillés.)

Un système autonome pourrait avoir de nombreux RR. Un RR traite les autres RR comme n'importe quel autre locuteur BGP interne. Un RR pourrait être configuré pour avoir d'autres RR dans un groupe client ou un groupe non-client.

Dans une configuration simple, le backbone pourrait être divisé en plusieurs clusters. Chaque RR serait configuré avec d'autres RR comme pairs non-clients (ainsi tous les RR seront entièrement maillés). Les clients seront configurés pour maintenir une session IBGP uniquement avec le RR de leur cluster. Grâce à la réflexion de route, tous les locuteurs IBGP recevront des informations de routage réfléchies.

Il est possible dans un système autonome d'avoir des locuteurs BGP qui ne comprennent pas le concept de réflecteurs de route (appelons-les locuteurs BGP conventionnels). Le schéma de réflecteur de route permet à de tels locuteurs BGP conventionnels de coexister. Les locuteurs BGP conventionnels pourraient être membres soit d'un groupe non-client soit d'un groupe client. Cela permet une migration facile et progressive du modèle IBGP actuel vers le modèle de réflexion de route. On pourrait commencer à créer des clusters en configurant un seul routeur comme RR désigné et en configurant d'autres RR et leurs clients comme des pairs IBGP normaux. Des clusters supplémentaires peuvent être créés progressivement.