Tuesday, August 23, 2011

Configuring BGP - Redundant Route Reflectors

In my previous blogtorial we saw how we can deploy route reflectors to circumvent the need for iBGP full mesh design. And my good friend "IT GURU" Tom brought up a good point about redundancy. So in this blogtorial we are going to see how we can configure dual route reflectors to avoid single point of failure (SPOF).


Consider the topology below.


Imagine that R3 and R4 in Sparks, R5 and R6 are in Vegas and R1 in Reno and R2 in Wells. If Reno Route reflector goes down all remote locations will still able to get to all other locations. 


Let's get started!! 
First let's configure the interfaces, description, IGP (OSPF), BGP on all the remote routers R3, R4, R5, and R6.
R3 and R4 Config

R5 and R6 Config
Alright now all the remote routers are ready to BGP peer and start advertising their subnets including the /24 that's on their LAN. Now let's get the 2 route reflectors configured. 

R1 and R2 Config
R1 and R2 BGP Config. Notice that all remote routes are route reflector client, however R1 and R2 are just iBGP peer.
Let's verify our settings, do a few show commands, and ping a few things to make sure we have connectivity.

All is well with BGP peers and routes are received as expected. 
All the remote routers are also good to go. Note than R3 can ping the network on R6. 
Show ip route to make sure the right routes are installed in the routing table.
Now what would happen if R1 becomes unavailable? R3 still should be able to ping R6. So let's shut R3's interface which connects to R1 and see what happens. 

Interface shutdown, lost connectivity to R1, BGP down with R1 and pinging R6's network still works through R2. 

As you can see if R1 goes down, all the routers will still have connectivity with everything. 

Troubleshooting: 
Clear ip bgp 
debug ip routing (as you may have recursive routing loops if IGP is not functioning properly)