Admin Distance Bug?

Granted, this is a duplicate post as the one posted by Jeremy Stretch here. When I first read his post, I just couldn’t believe it so I thought I’d lab it myself. However, do notice that my lab here is just slightly different:

  • I am advertising two networks (different from Jeremy’s lab)
  • The two routing protocols have been set with identical administrative distances (Jeremy does this for the advertised route instead)
  • I am assuming that the IOS version running on my routers is more recent (potentially different from Jeremy’s lab)
  • Since I’m using Gig interfaces, I’ve updated the OSPF auto-cost ref. bandwidth to 1000 Mbps (different from Jeremy’s lab)
  • I am comparing additional routing protocols – EIGRP, OSPF & ISIS (different from Jeremy’s lab)
NOTE: To install a route in the routing table, the following criteria is considered, in order of priority:

  1. Routing protocol administrative distance – in this case, both protocols will be matched
  2. The route with the lowest metric wins
  3. Prefix length

This can also be verified here.

Now let’s take a look at my results.


OSPF & EIGRPEIGRP & IS-ISOSPF & IS-IS

In this case, I would expect to see OSPF routes installed in the routing table!!
R1 Config R2 Config

The first routing table screenshot is a result of when Gi1 interface is shut down. You can see that the ISIS route for both advertised routes is 10.

Once both interfaces are enabled, we can see that EIGRP routes are installed in the routing table – despite the admin distance being the same for both routing protocols and the ISIS metrics being lower.

Once again, in this case I would also expect to see ISIS routes installed in the routing table!!
R1 Config R2 Config

Notice that OSPF metrics are lower than ISIS metrics; also, the admin distance is indeed equal.

In this case, the routing process would keep whichever routes got installed first. So even though OSPF metrics are lower, if ISIS routes are installed first, OSPF does not replace the ISIS routes! And I did allow for the expiry timers to pass.
R1 Config R2 Config

With this results in hand, I can only conclude this is a bug. It also seems that the routing process is somehow giving priority to EiGRP when against both ISIS and OSPF.

I will see at some stage, maybe I lab this on JunOS and see what results I get. Though it’s unlikely I’d have EIGRP available.


 

Thank you,

Rafael A. Couto Cabral • LinkedIn Profile
Cisco​ | F5 | VMware Certified • PRINCE2 Practitioner

Originally posted 2019-04-26 10:00:21.

Related Post

Comments are closed.