The other day my colleague stumbled upon a question in his studies (towards the CCNP route exam) and posed it to me. Initially I had no clue what the answer was, but figured it would make for a good topic of a first post.

The Question:

Say you administer a network with Cisco routers that uses BGP to peer with two upstream providers (eBGP) who both advertise you the same destination (i.e. a default route, 0.0.0.0/0). You also use BGP as your internal routing protocol (iBGP) and are re-advertising routes to all internal peers. I’ve included a quick diagram below.

ibgp-vs-ebgp

Given the above, you as the admin want to use AS200 as the primary exit point for all traffic. How would you complete this?

The Problem:

Thinking about the problem and looking at the diagram, my first thought (and my mistake, which I’ll elaborate on later) was to compare the AD (administrative distance) values of the routes received, since the length of the route received from both the iBGP and eBGP peers is the same and because I remembered with Cisco they have different values; with eBGP (AD of 20) being preferred over iBGP (AD of 200) as a lower value is preferred over a higher one.

With that thought process, I decided that the routes received via eBGP would always be preferred as the lower AD would take preference, and so the only way to make the router connected to AS300 use its’ iBGP path would be to change the AD of iBGP to be lower (and therefore better) than that of eBGP, right?

Testing:

Initial Setup:

I’ve set up GNS3 with the topology above and have given the routers serial links between each other. I’m using Cisco 7200’s as my virtual routers and am running 15.2(4)M7 code.

ibgp-vs-ebgp-gns

For addressing I’ve gone with a /24 between each device in the format 192.168.x.y/24, where x is the interface number and y is the router number. So R1’s address on the interface to R2 would be 192.168.1.1/24:

Next we’ll configure BGP on each of the devices. Don’t forget to configure next-hop-self on the routers we control otherwise we won’t be able to reach the routes that are re-advertised by our routers. I’ve again shown the configuration of R1:

And lastly  we’ll confirm that all peers are up before we start advertising anything:

Next we will advertise the default route from R3 and R4. Configuration of R3 below:

We can now check that both routers are receiving the advertisements:

Both routers are preferring the route that they received via their external peer, which is what I expected.

Modifying the AD:

Now that we have everything set up, lets attempt to use AS200 as the preferred path on both routers.

As we already know this is the case on R1, we simply need to change the administrative distance on R2 for routes received from R1. We can do this by using the command distance 19 192.168.1.1 0.0.0.0  which sets all routes received from the neighbour 192.168.1.1 with an AD of 19 (and therefore better than the eBGP AD of 20)

But wait, this hasn’t changed the preferred route?

The Solution:

To figure out why this happens, we need to think about how a route is installed in the routing table. There are several parts to this process:

– Routing processes (protocols) determine the best route for each destination (using their metric) and attempt to install these into the routing table.

– The router then receives all routes attempting to be installed by all processes and if there are any conflicting routes (routes to the same destination) then AD is used as a tie breaker before placing one into the routing table to be used for forwarding.

Simply put, AD is only evaluated when there are multiple paths to the same destination attempting to be installed by more than one routing process. So in our situation, because iBGP and eBGP are a part of the same process on a Cisco router, the BGP process chooses only one of the 0.0.0.0/0 routes to attempt to install into the routing table and therefore AD is not evaluated.

However, if we did have the same route (0.0.0.0/0) being put forward by another routing process, i.e. OSPF, AD would be the tie breaker.

 

So how does BGP choose the best path then?

Going back to our example; before our routers can install the route 0.0.0.0/0 into their routing table, it needs to be received by the BGP process which picks the route to install by the attributes that a route has.

In our case, BGP has gone through the route selection process and has reached step 7, where routes learnt by eBGP are preferred over routes learnt via iBGP.

I won’t cover how BGP makes its’ route selection here as that is another topic entirely. All you need to know is that BGP’s metric is actually a lot of different metrics (called attributes) that are compared one by one with other contender routes (other routes to the same destination received from other peers) until there is a difference and the tie is broken for a best route to be chosen.

 

To solve our problem, we can use the metric called ‘local preference’. This one is number 2 on the list of attributes, meaning it is looked at second (after a Cisco proprietary attribute called weight) to see if it can be used as a tie breaker.

We can check the local preference of each route that we have received using the command show ip bgp:

Here we can see that the local preference of both routes received is 100 (lines 9 and 13), which is also the default local preference value for all BGP routes.

In order to make the local preference for one of our routes higher than the other (a higher number is preferred with local preference), we would apply a route-map to the neighbor we want to change. For this problem I’ll set the local preference of the peering to AS200 higher than 100 to prefer this over all other peers.

We need to clear the neighbor for this to take effect as well:

Now, when we check BGP, we can see that it has chosen the iBGP route instead:

Lastly, AD comes back into play when the route is installed into the routing table. If the installed route was learnt from an eBGP peer, the route would have an AD of 20 and if it was instead learnt by iBGP it would instead have an AD of 200.

If we check the routing table on R2, we can see this has now been installed; with an AD of 19 that we set earlier as well: