Una ulteriore soluzione per introdurre la scalabilità delle connessioni iBGP è l'utilizzo di particolari router, detti Route Reflectors. Come il nome lascia facilmente intendere, questi router hanno il compito di replicare agli altri router le rotte che apprendono, la particolarità è che fanno questo anche se apprendono tali rotte da connessioni iBGP, ricordiamo infatti che il comportamento comune è quello di non annunciare le rotte apprese tramite iBGP.

Sostanzialmente i route reflectors hanno il compito di fare da “server centralizzato” per la diffusione delle rotte fra i router appartenenti ad uno stesso dominio. Altri router possono registrarsi come client di un route reflector e dipendere da questo per ottenere le rotte che sono state apprese da altri router BGP dello stesso AS.

In Figure 30 i router R1, R2, RN sono client del route reflector RR che invece con RX, RY, RZ partecipa ad una iBGP full mesh. Da questo esempio risulta chiaro come un route reflector possa comportarsi anche come un comune router BGP in alcuni casi.

Il comportamento del route reflector può essere semplicemente schematizzato:

• Se si apprende una rotta tramite una connessione eBGP, si seleziona la migliore rotta per quella destinazione e la si comunica a tutti gli altri peer. Questo comportamento è lo stesso adottato da un qualsiasi router BGP che ha una connessione eBGP verso altri AS.

• Se si riceve una rotta da uno dei peer non client (RX. RY, RZ della Figure 30) allora si seleziona la migliore rotta per quella destinazione e la si comunica tramite le connessioni iBGP a tutti i peer client (R1, R2, RN).

Poiché il route reflector non è altro che un approccio centralizzato alla diffusione delle informaizoni sulle rotte, bisogna immaginare qualche meccanismo per evitare di avere un single point of failure. Il meccanismo utilizzato è generalmente quello della replicazione dei route reflector, permettendo ad ogni peer di essere client di almeno due route reflector. Poiché errori di configurazione potrebbero causare dei loop nella redistribuzione delle rotte, si aggiungono due informazioni ai messaggi di aggiornamento delle rotte:

• ORIGINATOR ID: l'identificatore di chi ha dato origine alla rotta;

• CLUSTER LIST: contiene la lista dei route reflector che hanno mandato il messaggio di UPDATE per questa rotta in questo AS.

Chiaramente queste informazioni vengono eliminate dal router BGP che annuncia la rotta all'esterno del proprio AS.

E' interessante notare che i route reflector, per aumentare la scalabilità, possono essere organizzati in gerarchie.