by ·1 Comment

While helping a friend, I recently stumbled upon an interesting issue with Administrative distances that confused me for a bit. But, when I took a step back and started going through the route selection processes step by step, it started making sense. The issue? With the default Cisco Administrative Distances, OSPF was winning from eBGP on a specific prefix.

First, let’s explain Administrative Distances (AD) a bit:
When adding a route to the Routing Information Base and there are multiple routes of the same length from different protocols, the router needs to decide which route to use. It can not compare based on the protocol’s metrics, because the protocols metrics all mean something else. So, routers use an Administrative Distance to break the tie. Cisco uses the following defaults:

  • 20 for eBGP
  • 110 for OSPF
  • 200 for iBGP.

Lower is better, so you would think that having a valid route in eBGP and in OSPF would always result in eBGP winning and installing it’s route. However, this is not always the case.
Here is the setup:

CE1 and CE2 redistribute BGP into OSPF and advertise a default to the Satellite

The satelites loopback address will function as the network we want to reach. This is 3.3.3.3/32. In this scenario, CE1 has routing information for the Satelite from three sources: eBGP via WAN, iBGP directly from the Satelite, and OSPF from the C router. Which way will the traffic go?

It seems OSPF has won, even though we have a route with a better Admin Distance from eBGP:

The line begins with an r, which means there is a RIB failure. Other prefixes recieved from this eBGP neighbor get installed correctly:

Did you notice what was missing from the 3.3.3.3/32? The > indicating best. Let’s see what the BGP on CE1 knows about 3.3.3.3:1)What does the next-hop mismatch mean? A debug ip bgp internal on CE2 shows the following, but I don’t know exactly what it means:

So, here we see iBGP winning the path selection within the BGP process. It will then install the route into the routing table, where we get a collision. AD’s are compared and OSPF wins with its 110 AD vs iBGP’s 200. BGP will never go back and compare the eBGP path to the current installed route, because it already did its own checks. Let’s see this in action with a debug ip routing on CE2, while we reload the Satelite
2) Now, this was even more fun, when reloading the satellite, I got into an update loop: both CE1 and CE2 recieved the iBGP route at the same time, and redistribute it into OSPF. After this, they both prefer the OSPF route from eachother and flush their own LSA 5. After which they both uninstall the OSPF route at the same time and prefer the iBGP route again, ad infinitum. :

The solution here? Since iBGP is basically used as an external route processor, you can adjust the AD for iBGP, so it will win from OSPF:

References   [ + ]

1. ↑ What does the next-hop mismatch mean? A debug ip bgp internal on CE2 shows the following, but I don’t know exactly what it means:

2. ↑ Now, this was even more fun, when reloading the satellite, I got into an update loop: both CE1 and CE2 recieved the iBGP route at the same time, and redistribute it into OSPF. After this, they both prefer the OSPF route from eachother and flush their own LSA 5. After which they both uninstall the OSPF route at the same time and prefer the iBGP route again, ad infinitum.