Route Reflectors – an alternative to full-mesh iBGP configuration

The typical fully-meshed iBGP configuration of routers can become very difficult to manage in large networks. Because of the increasing numbers of iBGP sessions the possibilities of scaling are limited. Therefore, in a large network, the full-mesh requirement for iBGP can be a big challenge.

Route reflection comes to solve the complexity of multiple peering configuration. Route reflection enables sharing of routing information among multiple routers without having to send the exact same information to each of them individually.

iBGP has the restriction of not allowing to redistribute the learned routes to other internal peers. Because of that, the routers should be fully interconnected, hence the full mesh requirement. iBGP neither has any loop prevention mechanism, and this is why you require route reflectors to be setup for large networks. Using the route reflection principle you can designate one or several of your routers as route reflectors. A route reflector is not limited by the re-advertising restriction anymore, allowing it to share routes with other iBGP speakers. You simply establish a BGP session from the route reflector to each internal peer and the iBGP full-mesh requirement is met.

Figure 1 shows the configuration of a single cluster with one route reflector. RR is configured as a route reflector redistributing routes among the connected internal peers.

 

As shown in Figure 2, you can have multiple clusters with the route reflectors configured as fully meshed internal peers. When a router advertises to RR1, RR1 further distributes the routes to the rest of route reflectors. These, in turn, readvertise the routes to their clients.

 

In Figure 3, RR2 and RR3 are route reflectors for Cluster 2 and Cluster 3 respectively. Rather than fully mesh these reflectors they can be grouped in a separate cluster for which RR1 will be the route reflector. All the routes advertised to RR2 will be readvertised within Cluster 2 and then, readvertised to RR1. RR1, in turn, distributes the routes among the Level 2 reflectors that further propagate the routes down their clusters.

 

As route reflection is a concept frequently used in various network configurations, we have added full support of route reflectors in Noction IRP 2.1. IRP can now announce routing updates to a route reflector that further propagates them to the edge routers. Bellow is a diagram depicting the IRP configuration within a topology that uses route reflection.

 

Infrastructures with route reflectors in place, be it of any configuration, can now use Noction IRP to reroute traffic across multiple ISPs based on critical performance metrics and achieve considerable reduction in packet loss, latency and network downtime.