iBGP route reflectors

September 18, 2009

It is by default that all BGP peers within the same autonomous systems must peer with each other to form a full mesh in order for each peer to be able to advertise routes to its adjacent peer.

“Disclaimer: BGP confederacies will not be tackled in this post”

**For example **

if routerB learns a new route from routerA, it wouldn’t be able to advertise the learned route to routerC and routerC would only be able to learn the route from routerA. Now imagine if your network isn’t fully meshed? well I am sure you guessed right! depending on your network infrastructure, routing on this advertised subnet from router A will be un-reachable through routerC and you will be having a big problem of convergence.

What if the peers cannot be meshed together?

It is possible when using standard iBGP to “force” a router to “reflect” the routes it learned to another adjacent peer. In simple words, routerB learned the route from routerA, routerB “reflects” that route to routerC.

Route Reflectors

As stated already, route reflectors eliminate the need for a full mesh setup, thus allow scalability but also a route reflector reduce data exchange between peers by only reflecting the best path. When setting up RR, you would be defining what is generally referred as a cluster (RR + client peers), in our example below, the RR is routerB and the client peers are routerA and routerC. This group is then defined as a cluster.

It is also important to understand how RR works.

As we said earlier, RR selects the best path when receiving a route from an iBGP peer; if the route had originated from a non-client iBGP peer (imagine routerD connected to routerA), this route will then be only reflected to all route reflectors clients (routerA and routerC for example), thus any other none-rr-clients needs to be fully meshed.  If the route nevertheless originates from either routerA or routerC, the route would then be reflected to both non-client and rr-client .

Now let’s see how we can set up a simple route reflector…

Configuration using a private ASN

Simple topology: [routerA] —– [ routerB] —– [ routerC]

routerB(config)#router bgp 64514 routerB(config-router)#neighbor remote-as 64514 routerB(config-router)#neighbor route-reflector-client routerB(config-router)#neighbor remote-as 64514 routerB(config-router)#neighbor route-reflector-client

Now routerB will be advertising routers learned from routerA to routerC and from routerC to routerA.

What more?

I am not going to reiterate what RFC 2796 addresses, thus I suggest a read at http://www.ietf.org/rfc/rfc2796.txt to learn more about RR loop detection and avoidance.