BGP Route Reflectors

One of the main points to remember about iBGP relationships is that iBGP assumes that all of the routers within a single AS are fully meshed.  That is, each router is peered to every other router within the same AS.  The purpose of this is namely to fix any issues around loop prevention.  You’ll recall the BGP uses the AS-Path attribute to prevent against loops.  A BGP speaker will drop any update it receives that has it’s own AS listed in the AS-Path attribute.  Since iBGP updates are sent within a single AS, the AS-path attribute isn’t updated and if iBGP speakers continued to forward updates, we would have routing loops.  Bottom line is that iBGP speakers will not forward iBGP learned routes to other iBGP peers. 

As you can imagine, in some designs, peering every router to every other router in the same AS could be quite the task.  One of the ways to get around this restriction is to use route reflectors.  I think the concept is best explained with an example so let’s just jump right into a topology…

Given this topology, and assuming that all of the routers are in AS 100, let’s peer each of the directly connected routers and see what we get…

As expected, each router did NOT forward any of the iBGP updates it heard to any of the other routers.  At this point, router2 has the most visibility of the network with 4 out of the 5 router loopbacks in it’s BGP table (it’s own and one for each BGP peer that it has). 

Peering each of the routers together would mean that I’d have to configure 12 more BGP sessions.  That would be a serious pain. 

This is where we can use route reflectors to save ourselves some pain and agony.  Let’s configure router2 as a route reflector to start with…

Once the configuration goes in you should see the sessions bounce and reset…

Now let’s see what we have on router3 which previously has 3 out of the 5 loopbacks…

We see that router3 now has all of the loopbacks.  So let’s talk about what a route reflector actually does.  You saw above the configuration isn’t all that involved.  We made router2 a route reflector just by telling it that it’s peers were route reflector clients.  By doing that, we’re telling router2 to sort of change the traditional rules of iBGP advertisements.  Essentially we tell router2 to act by the following rules…

-Advertise routes learned from route reflector clients to other route reflector clients AND non-route reflector clients.
-Routes learned from non-route reflector clients should ONLY be advertised to route reflector clients.

In the case above, we told router2 that all of it’s peers were route reflector clients.  When we did that, it used rule 1 above and advertised the loopbacks from routers 1, 3, and 5 to all of it’s peers (which happen to be routers 1, 3, and 5).  Lets’ modify the configuration a little to show rule 1 working with non-route reflector clients…

Looking at router5 we see that it has the same prefixes as before in it’s BGP table…

AKA – Things are still working the way they should since the other prefixes are being advertised by route reflector clients.  If a prefix was advertised to the route reflector (router2) from a non-route reflector client, router5 would no longer receive it since the normal rules of iBGP would apply. 

Looking at the iBGP table on router3, we can see that the route reflector is acting on rule 2 listed above and advertising routes learned from non-route reflector clients to other route-reflector clients…

We can tell this rule is working since router3 has the loopback for router5 (a non-route reflector client) in it’s BGP table.  Route reflectors sound hard, but if you remember the two rules listed above, they are much easier to work with and understand.

Now let’s take a look at a couple of the prefixes in the BGP table…

Looking at the router1 and the router2 loopbacks we note that there’s a difference in the output we are receiving.  Namely we notice that the first entry for 172.64.32.1 includes an additional line at the bottom of the output listing the ‘originator ID’ as well as the ‘Cluster list’.  These are two BGP attributes that are used by route reflectors.  Note that router3 believes that the originator for the 172.64.32.1 prefix is 10.0.0.14 and that the cluster list is 10.0.0.13.  Let’s check the diagram to make sure this makes sense…

Any guesses on what these fields mean or why these IPs are listed?  Its rather straight forward actually.  The cluster list includes a list of all route reflectors that reflect the route on it’s way to router3.  In this case, that’s just router2.  The originator ID is the router that originated the router which in this case is router1.  Taking a look at router1 and router2 we note that the IPs that are used for the cluster list and the originator ID are the BGP router IDs…

The BGP cluster ID can be changed with the ‘bgp cluster-id’ command under the BGP process.  The Originator ID will always be the BGP router ID. 

So now you might be wondering what the cluster list and the originator ID are used for.  Much like how eBGP uses AS-Path for loop prevention, iBGP uses these two attributes to fill a similar role.  BGP routers work off the following rules when it comes to the cluster list and the originator ID…

-If a BGP router receives a BGP update from an iBGP peer and detects it’s own router-ID in the originator ID field it will reject the update
-If a BGP router acting as a router reflector receives a BGP update from an iBGP peer and detects is own cluster ID in the cluster list it will reject the update.

Pretty simple right?  Let’s configure router3 to be a route reflector so we can see the cluster list in action…

At this point, all of our routers will have all of the loopbacks in their BGP table.  Let’s take a look at the 172.64.32.1 prefix on router 4 and see what we have…

Notice how the prefix is still originated by router1, but the cluster list now shows the IP addresses for router2 and router3.  These are the two route reflectors that reflected the update on it’s way to router4. 

We can see the cluster list loop prevention in action if we reset the BGP session between rotuer2 and router5.  Before we do that, let’s take a quick look at router2 and router3 to determine how they are sending BGP updates.  A handy command to look at where a BGP router will send updates is the ‘show ip bgp update-group’ command.  Let’s look at that on routers 2 and 3…

Here we can see that router2 has two separate update groups.  This means that there are two distinct sets of routers that will receive two separate sets of updates.  If all the routers were going to receive the same updates, there would only be one update group.  Here we can see that update group 1 consists of routers 3 and 1.  Update group 2 consists of router5.  This makes sense since only routers 1 and 3 are route reflector clients to router2.  The route reflector clients will always get the same set of updates.   

Router 3 has only one update group since all of it’s peers are route reflector clients.  Notice that both router2 and router3 list each other as members of the update group.  If we turn on BGP update debugging and clear the session on router5, we’ll eventually see this debug message on router2…

*Mar  3 10:19:08.011: BGP(0): 10.0.0.10 rcv UPDATE w/ attr: nexthop 10.0.0.6, origin i, localpref 100, metric 0, originator 172.64.32.5, clusterlist 10.0.0.17 0.0.0.0, path , community , extended community , SSA attribute
*Mar  3 10:19:08.011: BGP(0): 10.0.0.10 rcv UPDATE about 172.64.32.5/32 — DENIED due to: CLUSTERLIST contains our own cluster ID;

This is because router2 is reflecting the route to router3.  Router3 is then sending the route right back to router2. 

We can also see an example of the originator ID loop prevention mechanism by clearing the BGP session between router2 and router3…

*Mar  3 11:18:02.123: BGP(0): 10.0.0.10 rcv UPDATE w/ attr: nexthop 10.0.0.10, origin i, localpref 100, metric 0, originator 172.64.32.2, clusterlist 172.64.32.3, path , community , extended community , SSA attribute
*Mar  3 11:18:02.123: BGP(0): 10.0.0.10 rcv UPDATE about 172.64.32.2/32 — DENIED due to: ORIGINATOR is us;

Here we see that router3 is reflecting the router originated by router2 (172.64.32.2/32) back to router2.  Router2 sees it’s own originator ID in the update and drops it. 

There you have it.  A quick look at route reflectors in action!