Two routing protocols with the same AD
By stretch | Saturday, December 6, 2008 at 2:50 p.m. UTC
I came across an interesting question the other day (though I can't recall where): what happens when two routing protocol are given the same administrative distance? Administrative distance (AD) on IOS routers is used to prefer one routing protocol over another when both protocols carry a route to the same destination. Each routing protocol supported by IOS is assigned a default administrative distance:
- Connected routes - 0
- Static routes - 1
- EIGRP Summary - 5
- External BGP - 20
- EIGRP - 90
- OSPF - 110
- IS-IS - 115
- RIP - 120
- Internal BGP - 200
For example, because 90 is lower than 120, a router will favor an EIGRP route to 172.16.0.0./16 over a RIP route to 172.16.0.0/16 (note that these routes have an identical length; more-specific routes will always be favored over less-specific routes regardless of the AD set for a protocol). Most deployments leave these administrative distances unmodified, but they can be changed for each protocol using the
distance command under the appropriate process configuration.
To observe what happens when two protocols are assigned the same administrative distance, we can setup a simple lab:
R1 has two equal connections to R2: EIGRP is run over one while OSPF is run over the other. R2 advertises a route to 172.16.0.0/16 via both of these protocols. Normally, the EIGRP route would be favored as it has, by default, a lower administrative distance of 90, versus OSPF's 110. However, we can tweak the ADs of both protocols to be equal:
R1(config)# router eigrp 1 R1(config-router)# distance 100 10.0.0.2 0.0.0.0 R1(config-router)# router ospf 1 R1(config-router)# distance 100 10.0.0.6 0.0.0.0
The configurations above instruct the router to assign an AD of 100 to EIGRP routes learned from 10.0.0.2 and OSPF routes learned from 10.0.0.6. Since both routes for 172.16.0.0/16 are assigned the same AD, which will win the spot in the routing table? You might assume that the OSPF route would be chosen as it would have a lower numeric metric than the EIGRP route, which it does, but in fact the EIGRP route is favored:
R1# show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set D 172.16.0.0/16 [100/409600] via 10.0.0.2, 00:20:11, FastEthernet0/0 10.0.0.0/30 is subnetted, 2 subnets C 10.0.0.0 is directly connected, FastEthernet0/0 C 10.0.0.4 is directly connected, FastEthernet0/1
D in front of the 172.16.0.0/16 route above shows that the EIGRP route is active in the routing table, with an administrative distance of 100. We can confirm that the OSPF route is still being received by cutting off the EIGRP neighbor:
R1(config)# interface f0/0 R1(config-if)# shutdown R1(config-if)# ^Z R1# show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set O 172.16.0.0/16 [100/11] via 10.0.0.6, 00:00:16, FastEthernet0/1 10.0.0.0/30 is subnetted, 1 subnets C 10.0.0.4 is directly connected, FastEthernet0/1
What's interesting is that here we've seen one route (from EIGRP) favored over another (from OSPF) with the same AD and a lower metric. It seems like IOS might follow the same order of preference as outlined in the above list of ADs, but we've only pitted EIGRP against OSPF here. If anyone feels compelled to experiment with assigning other protocols the same AD please share your observations in the comments.
Posted in Routing
December 6, 2008 at 3:30 p.m. UTC
Interesting experiment - I just pitted a couple others, all set to AD 100:
- EIGRP vs. RIP: EIGRP
- RIP vs. OSPF: RIP (interestingly)
December 6, 2008 at 4:30 p.m. UTC
I think it has to do with the IP address. In your case you choose to use EIGRP (10.0.0.2) with a lower IP address than OSPF (10.0.0.6). If OSPF has the lower IP address I think OSPF is chosen. If they have the same IP address IOS will go for the MAC address.
Thanks for a really interesting blog.
December 6, 2008 at 7:03 p.m. UTC
I just wanted to chime in with my first comment here and tell you that I have been reading your blog for several months, and it has quickly become part of my must-read list.
With regards to this post, I am under the impression the selection criteria for which route is inserted into the routing table is:
- Prefix Length - A more specific route is always selected over a less specific route.
- Currently Configured Administrative Distance
- Default Administrative Distance
You could very easily end up with a routing loop if metric were taken into account if the configured administrative distance was the same between two routes of different routing protocols. Additionally, comparing the metric from two different routing protocols is not effective since the method of determining that metric is different for every routing protocol.
December 6, 2008 at 7:23 p.m. UTC
@ Matthew: nope, tried it vica versa still EIGRP wins. I guess the fact it's Cisco proprietary is the tiebreaker :)
December 7, 2008 at 5:26 a.m. UTC
I did some testing on this in my lab awhile ago and I always just assumed it was Cisco being Cisco :P
December 7, 2008 at 9:46 a.m. UTC
i've allready played with such situation :) correct answer (can be found somewhere on cisco.com) is: default AD of EIGRP is lower, so EIGRP is preffered.
December 7, 2008 at 5:57 p.m. UTC
I did something like this a while ago, but I guess I was running two instances of the same routing protocol (for example, two OSPF processes). The metric is completely ignored (it's not comparable in a generic case anyway) and the route that changes later wins (a new route kicks out an existing route from the IP routing table if the new route's AD is lower or equal to the old route's AD).
December 8, 2008 at 2:29 a.m. UTC
I couldn't find an "official" link but have always been under the impression that, as others have stated, the default AD would be the tie-breaker. Seems that behavior is not necessarily consistent in practice, though. Bottom line is that AD is local to a given router only, so just avoid the situation of matching AD altogether and be done with it! ;~)
December 9, 2008 at 1:48 a.m. UTC
Yeah, think of it this way. Within a single routing process, that process will select its best route(or routes for some protocols) and that route becomes eligible for the routing table. The router then takes all the eligible "best" routes from all the processes and selects the one with the lowest AD to put in the routing table. If there are two routes with equal AD's, then the one that comes from the process with the lowest default AD wins. The thing to keep in mind, and several others have mentioned it, is that the metric is only significant within that process.
Try the above lab with a static route and EIGRP, only set the static route's AD to 90. You can also debug each routing process, and the routing table, to see the whole thing take place.
December 11, 2008 at 9:47 p.m. UTC
In the case of an AD tie between different protocols, Cisco will then use its default AD for each protocol.
March 21, 2011 at 5:34 p.m. UTC
I made some researches about this topic. Please check my website:
April 14, 2014 at 12:08 p.m. UTC
this question i have been asked in an interview and i tried it with RIP and OSPF. In my case OSPF learned routes are installed in routing table.
April 10, 2016 at 9:29 p.m. UTC
I tested this in my GNS3 lab and I did not get one route chosen over the other.
Both routes were still showing - see below
Any ideas why my routers behave like this?
output of "show ip route" on R1 D 172.16.0.0/16 [100/409600] via 10.0.0.2, 00:03:28, FastEthernet0/0 O 172.16.0.1/32 [100/11] via 10.0.0.6, 00:03:25, FastEthernet0/1
GNS3 1.3.9 IOS: c3725-advipservicesk9-mz.124-3.image
July 28, 2016 at 5:53 p.m. UTC
@Konrad you have 2 different routes, a /16 and a/32, therefore two different routes will show.