BGP Admin Distance

When chatting with both colleagues and customers about BGP path manipulations, I've picked up on something interesting – the concept of admin distance can often lead to some head-scratching moments.

So, in this blog post, I'm going to take you through a few links and hands-on labs. Our goal? To unravel the mysteries surrounding admin distance and its pivotal role in the BGP best path selection process. Let's dive in!

The basics

To kick things off, let's take a quick refresher on the fundamental concepts.

What is Admin distance?

Administrative distance is the feature that routers use in order to select the best path when there are two or more different routes to the same destination from two different routing protocols. (Source: Cisco BGP documentation

The important part is }from two different routing protocols.

The same concept, in other words:

"When you receive information about the same network via IGP and eBGP, eBGP will be preferred due to administrative distance on Cisco devices." (Source: BGP ZEro to Hero

If you, like me, prefer diagrams to visualize concepts:

To summarize: }each protocol selects its own best route, the router installs in RIB the best route with the best (lower) AD.

What is the AD of BGP?

For Cisco devices in general:

eBGP Administrative distance (AD) is 20, iBGP Administrative distance (AD) is 200

What is the role of the AD in the BGP best path selection algorithm?

The answer is simple: }NONE

The BGP Best Path Selection Algorithm doesn't care about the AD.

If, by chance, all the route attributes that were taken into account during the earlier steps of the algorithm turn out to be the same, eBGP is preferred over iBGP. This rule holds true, irrespective of the Admin Distance (AD) settings on the router for both iBGP and eBGP.

From the RFC4171:

d) If at least one of the candidate routes was received via EBGP, remove from consideration all routes that were received via IBGP.

Interestingly, the Admin Distance (AD) doesn't come into play here – it's neither mentioned nor factored into the equation.

Where does the confusion originate from?

My guess is that it is believed that in the algorithm eBGP is always preferred over iBGP because of its AD, while in reality the AD is only taken in consideration when BGP is compared to other protocols, }after the best BGP route was selected.

How can the router prefer iBGP over eBGP?

It is sufficient to make the route coming from iBGP preferable by changing any of the attributes considered before the eBGP-iBGP comparison.

No special rules, just follow the algorithm.

To validate the behavior of BGP, I prepared a simple lab with some examples.

In the lab we'll focus on R4 that will receive the same prefix from R1 (eBGP), R3 (iBGP) and R2 (IGP).

LAB Topology

L1 diagram

L3 diagram

BGP diagram

LAB 1: BGP AD and Best Path

In the first lab we investigate if the AD has any impact in the BGP best Path Selection Algorithm (we already know it hasn't).

Assumption: if all the previous attributes of the routes being compared are the same, eBGP is always preferred over iBGP

In the lab R1 advertises its Loopback0 (1.1.1.1/32) to R3 and R4 via eBGP. R3 advertises the prefix to R4 via iBGP. R4 receives the same prefix from eBGP(R1) and iBGP(R3).

On R4 we look at the routing table to confirm that R4 prefers the route via R1 (eBGP) to reach 1.1.1.1:

1R4#sh ip bgp
2BGP table version is 2, local router ID is 4.4.4.4
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4              r RIB-failure, S Stale
5Origin codes: i - IGP, e - EGP, ? - incomplete
6
7   Network          Next Hop            Metric LocPrf Weight Path
8* i1.1.1.1/32       10.0.13.1                0    100      0 65100 i
9*>                  10.0.14.1                0             0 65100 i

The distance (a.k.a. AD) values on R4 are set to default:

1sh ip protocol | i Protocol | Distance:
2Routing Protocol is "bgp 65200"
3  Distance: external 20 internal 200 local 200

So far so good. Now we use assign AD 210 to eBGP on R4 using the distance command.

Command sintax:

1distance bgp external-distance internal-distance local-distance

Apply the change on R4:

1R4(config-router)#distance bgp 210 200 200

Verify the change is applied:

1R4#sh ip protocol | i Protocol | Distance: 
2Routing Protocol is "bgp 65200"
3  Distance: external 210 internal 200 local 200

Has anything changed in the routing table of R4?

1R4#sh ip bgp
2BGP table version is 2, local router ID is 4.4.4.4
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
4              r RIB-failure, S Stale
5Origin codes: i - IGP, e - EGP, ? - incomplete
6
7   Network          Next Hop            Metric LocPrf Weight Path
8* i1.1.1.1/32       10.0.13.1                0    100      0 65100 i
9*>                  10.0.14.1                0             0 65100 i

The answer is no. Despite eBGP being set with AD 210 and iBGP still having the default AD 200, eBGP is preferred.

Notice that at the moment, BGP is not competing against any other IGP.

Let's have a look at the RIB of R4:

 1R4#sh ip route 1.1.1.1
 2Routing entry for 1.1.1.1/32
 3  Known via "bgp 65200", distance 210, metric 0
 4  Tag 65100, type external
 5  Last update from 10.0.14.1 00:56:03 ago
 6  Routing Descriptor Blocks:
 7  * 10.0.14.1, from 10.0.14.1, 00:56:03 ago
 8      Route metric is 0, traffic share count is 1
 9      AS Hops 1
10      Route tag 65100

The eBGP prefix won the internal BGP challenge, and since there is no other competitor it is installed in RIB.

LAB 2: iBGP preferred over eBGP

From the previous lab we confirmed that the AD assigned to iBGP and eBGP has no influence on the BGP best path selection algorithm.

That means that we can/need to use any of the path attributes taken in consideration in the previous steps of the algorithm to influence the best path selection.

In the next lab we'll keep the default AD values for iBGP and eBGP, and assign a better Local Preference to iBGP.

Will R4 prefer iBGP over eBGP?

The current status: eBGP is preferred, R1 is the next-hop.

1   Network          Next Hop            Metric LocPrf Weight Path
2* i1.1.1.1/32       10.0.34.3                0    100      0 65100 i
3*>                  10.0.14.1                0             0 65100 i

Now on R4 we create a route-map to assign LocalPreference 120:

1R4(config)# route-map LP-120 permit 10
2  set local-preference 120

We apply the route map on R4 to all the routes received from the iBGP session with R3:

1R4(config)#router bgp 65200
2R4(config-router)#neighbor 10.0.34.3 route-map LP-120 in 

After the change R4 prefers the route via R3 received from iBGP over the route via R1 received form eBGP. Notice the next-hop changed to R3:

1   Network          Next Hop            Metric LocPrf Weight Path
2*>i1.1.1.1/32       10.0.34.3                0    120      0 65100 i
3*                   10.0.14.1                0             0 65100 i

LAB 3: BGP and IGP

We've come to understand that Administrative Distance (AD) doesn't play a part in the BGP best path algorithm. This revelation prompts us to delve deeper and uncover the true significance of AD in the realm of networking. So, what exactly is the role of AD? Let's dive in and find out.

"When you receive information about the same network via IGP and eBGP, eBGP will be preferred due to administrative distance on Cisco devices." (Source: BGP Zero to Hero

}Notice the "on Cisco devices" part. Other vendors may use different values for AD.

Let's see what happens if R4 receives the same prefix from R1 via eBGP, from R3 via iBGP and from R2 via IGP (OSPF).

 1R4#sh ip route 1.1.1.1
 2Routing entry for 1.1.1.1/32
 3  Known via "bgp 65200", distance 20, metric 0
 4  Tag 65100, type external
 5  Last update from 10.0.14.1 00:05:11 ago
 6  Routing Descriptor Blocks:
 7  * 10.0.14.1, from 10.0.14.1, 00:05:11 ago
 8      Route metric is 0, traffic share count is 1
 9      AS Hops 1
10      Route tag 65100

eBGP with AD 20 is preferred over OSPF with AD 110.

What happened here? eBGP won over iBGP when the BGP best path selection algorithm was executed. Then the eBGP route competed against the OSPF route and won again, since AD 20 of eBGP is preferred over AD 110 of OSPF.

But what happens if we set eBGP AD to 120 instead?

• OSPF: AD 110
• eBGP: AD 120
• iBGP: AD 200

1R4(config)#router bgp 65200
2R4(config-router)#distance bgp 120 200 200
3R4#sh ip protocol | i Protocol | Distance: 
4Routing Protocol is "bgp 65200"
5  Distance: external 120 internal 200 local 200

The route that goes in the RIB comes from OSPF:

1R4#sh ip route 1.1.1.1
2Routing entry for 1.1.1.1/32
3  Known via "ospf 1", distance 110, metric 21, type intra area
4  Last update from 10.0.24.2 on FastEthernet0/1, 00:00:30 ago
5  Routing Descriptor Blocks:
6  * 10.0.24.2, from 1.1.1.1, 00:00:30 ago, via FastEthernet0/1
7      Route metric is 21, traffic share count is 1

The eBGP prefix won again the Best Path Algorithm, but then its AD (artificially set to 120) was compared to other the candidates and lost, since OSPF now has a better AD (110).

In the BGP table we see the route marked as r meaning RIB-failure, the route is valid but it failed to be installed in RIB because a better route (either static or from IGP) won:

1R4#sh ip bgp
2   Network          Next Hop            Metric LocPrf Weight Path
3r> 1.1.1.1/32       10.0.14.1                0             0 65100 i
4r i                 10.0.13.1                0    100      0 65100 i

This is exactly what we expect from AD, to be the tie-breaker when the same prefix is received from different protocols.

LAB 4: eBGP and OSPF with same AD 110

In the next lab we set on R4 AD 110 to eBGP, meaning both eBGP and OSPF will have the same AD.

• eBGP distance 110
• OSPF distance 110 (default)
• iBGP distance 200 (default)

We start from the previous lab, with R4 preferring the path via eBGP to R1:

 1R4#sh ip route 1.1.1.1 
 2Routing entry for 1.1.1.1/32
 3  Known via "bgp 65200", distance 20, metric 0
 4  Tag 65100, type external
 5  Last update from 10.0.14.1 00:06:01 ago
 6  Routing Descriptor Blocks:
 7  * 10.0.14.1, from 10.0.14.1, 00:06:01 ago
 8      Route metric is 0, traffic share count is 1
 9      AS Hops 1
10      Route tag 65100

Then we set AD 110 to eBGP:

1R4(config)#router bgp 65200
2R4(config-router)#distance bgp 110 200 200
3R4#sh ip protocol | i Protocol | Distance:
4Routing Protocol is "bgp 65200"
5  Distance: external 110 internal 200 local 200

Let's have a look again:

 1R4#sh ip route 1.1.1.1
 2Routing entry for 1.1.1.1/32
 3  Known via "bgp 65200", distance 110, metric 0
 4  Tag 65100, type external
 5  Last update from 10.0.14.1 00:00:07 ago
 6  Routing Descriptor Blocks:
 7  * 10.0.14.1, from 10.0.14.1, 00:00:07 ago
 8      Route metric is 0, traffic share count is 1
 9      AS Hops 1
10      Route tag 65100

eBGP with AD 110 wins over OSPF with the same AD 110. Why?

Now let's try the oppostite.

LAB 5: eBGP and OSPF with same AD 20

In this lab, we set AD 20 to OSPF and eBGP, to confirm the original metric is taken in consideration.

• eBGP distance 20 (default)
• OSPF distance 20

Remove the config from the previous lab:

1R4(config)#router bgp 65200
2R4(config-router)#no distance bgp 110 200 200

And set the OSPF distance to 20:

1R4(config)#router ospf 1
2R4(config-router)#distance 20

Verify:

1R4#sh ip protocol | i Protocol | Distance:
2
3Routing Protocol is "ospf 1"
4  Distance: (default is 20)

Let's check the RIB:

 1R4#sh ip route 1.1.1.1
 2Routing entry for 1.1.1.1/32
 3  Known via "bgp 65200", distance 20, metric 0
 4  Tag 65100, type external
 5  Last update from 10.0.14.1 00:01:33 ago
 6  Routing Descriptor Blocks:
 7  * 10.0.14.1, from 10.0.14.1, 00:01:33 ago
 8      Route metric is 0, traffic share count is 1
 9      AS Hops 1
10      Route tag 65100

eBGP wins again.

Wathever the value, 20 or 110, when OSPF and eBGP have the same custom AD, the original AD of eBGP makes it preferred over OSPF.

LAB 6: iBGP and OSPF with same AD 110

Now we shut the eBGP sessiong between R1 and R4 and focus on OSPF and iBGP only.

1R4(config)#router bp 65200
2R4(config-router)#neighbor 10.0.14.1 shut

We restore AD 110 to OSPF, that was changed in the previous lab:

1R4(config)#router ospf 1
2R4(config-router)#no distance 20

We set AD 110 to iBGP on R4:

1R4(config)#router bgp 65200
2R4(config-router)#distance bgp 20 110 110

In summary:

• iBGP distance 110 (default is 200)
• OSPF distance 110 (default)

Verify the distance:

1R4#sh ip protocol | i Protocol | Distance:
2Routing Protocol is "ospf 1"
3  Distance: (default is 110)
4Routing Protocol is "bgp 65200"
5  Distance: external 20 internal 110 local 110

Then we clear BGP to apply the change:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

R4#clear ip bgp *
*Mar  1 05:02:53.850: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 05:02:54.554: RT: delete route to 1.1.1.1/32
*Mar  1 05:02:54.554: RT: NET-RED 1.1.1.1/32
*Mar  1 05:02:54.554: RT: delete network route to 1.0.0.0
*Mar  1 05:02:54.558: RT: NET-RED 1.0.0.0/8
*Mar  1 05:02:54.574: %BGP-5-ADJCHANGE: neighbor 10.0.34.3 Down User reset
*Mar  1 05:02:54.590: RT: add 1.1.1.1/32 via 10.0.24.2, ospf metric [110/21]
*Mar  1 05:02:54.594: RT: NET-RED 1.1.1.1/32
*Mar  1 05:02:55.666: %BGP-5-ADJCHANGE: neighbor 10.0.34.3 Up 
*Mar  1 05:02:55.762: RT: closer admin distance for 1.1.1.1, flushing 1 routes
*Mar  1 05:02:55.766: RT: NET-RED 1.1.1.1/32
*Mar  1 05:02:55.766: RT: add 1.1.1.1/32 via 10.0.34.3, bgp metric [110/0]
*Mar  1 05:02:55.770: RT: NET-RED 1.1.1.1/32

Notice what happens, line by line:

• line 3: the route to 1.1.1.1 learned from BGP is deleted
• line 8: the route learned from OSPF is installed (the BGP peer is still down)
• line 10: the BGP peer comes up and advertises the prefix to 1.1.1.1
• line 13 the BGP route learned from R3 via iBGP is installed in RIB (action = add)

The RIB confirms:

 1R4#sh ip route 1.1.1.1
 2Routing entry for 1.1.1.1/32
 3  Known via "bgp 65200", distance 110, metric 0
 4  Tag 65100, type internal
 5  Last update from 10.0.34.3 00:21:08 ago
 6  Routing Descriptor Blocks:
 7  * 10.0.34.3, from 10.0.34.3, 00:21:08 ago
 8      Route metric is 0, traffic share count is 1
 9      AS Hops 1
10      Route tag 65100

So what just happened? Despite iBGP and OSPF having the same AD 110, and iBGP having a native AD (200) higher than OSPF, the prefix learned from iBGP is installed in RIB.

Recap:

• OSPF AD 110
• iBGP AD 100, native AD 200
• eBGP AD 20 --> this is used to compare BGP and OSPF

LAB 7: iBGP and OSPF with same AD 200

Now we set AD 200 to both OSPF and iBGP, to confirm what we learned from Lab 6.

1R4(config)#router bgp 65200
2R4(config-router)#no distance bgp 20 110 110

And

1R4(config)#router ospf 1
2R4(config-router)#distance 200

The logs clearly show that the BGP route is installed:

1*Mar  1 05:26:18.462: RT: delete route to 1.1.1.1/32
2*Mar  1 05:26:18.462: RT: delete network route to 1.0.0.0
3*Mar  1 05:26:18.478: RT: add 1.1.1.1/32 via 10.0.24.2, ospf metric [200/21]
4*Mar  1 05:26:18.482: RT: closer admin distance for 1.1.1.1, flushing 1 routes
5*Mar  1 05:26:18.482: RT: add 1.1.1.1/32 via 10.0.34.3, bgp metric [200/0]

The router compared the same prefix 1.1.1.1/32 coming from OSPF with AD 200 and original AD 110, and from iBGP with AD 200, and BGP won?

The reason is the same from the previous lab: when the AD is the same, the AD taken in consideartion is 20 (eBGP), not 200 (iBGP).

So BGP wins again:

 1R4#sh ip route 1.1.1.1
 2Routing entry for 1.1.1.1/32
 3  Known via "bgp 65200", distance 200, metric 0
 4  Tag 65100, type internal
 5  Last update from 10.0.34.3 00:03:05 ago
 6  Routing Descriptor Blocks:
 7  * 10.0.34.3, from 10.0.34.3, 00:03:05 ago
 8      Route metric is 0, traffic share count is 1
 9      AS Hops 1
10      Route tag 65100

WRAP UP

This post is longer than I initially expected, I added a few more labs to clarify the role of administrative distance in choosing the best route in relation to BGP, but also when comparing to other protocols.

Feel free to provide feedback to help correct any mistakes or enhance the clarity of the explanation. Your input is highly appreciated!

Links

• CISCO tech notes: BGP Best Path Selection Algorithm
• What is Admnistrative Distance? from Cisco documentation
• Two routing protocols, Same administrative distance? by Brad Hedlund
• Two routing protocols with the same AD by PacketLife.net
• Administrative Distance by Łukasz