Troubleshooting Mixed Protocol Environments: Administrative Distance Conflicts

When you're running a single routing protocol, administrative distance (AD) is largely invisible. You configure OSPF or EIGRP, routes show up in the table, and life is good. The moment you introduce a second protocol into the mix, whether it's a migration scenario, redistribution boundary, or a legacy network segment, AD becomes the deciding factor in what traffic actually does. Misunderstand it here, and you'll spend hours chasing a routing loop that shouldn't exist or wondering why your carefully engineered path is being ignored.

This post covers how to identify, diagnose, and resolve administrative distance conflicts in mixed protocol environments with the precision the ENARSI exam expects and production networks demand.

Why AD Conflicts Happen in Mixed Protocol Environments

Cisco's default AD values establish a preference hierarchy that wasn't designed for your specific network. When two protocols learn about the same destination, the router installs only the route with the lowest AD. This is fine in isolation, but during redistribution or protocol migrations, it creates traps:

• Redistribution loops: Routes redistributed from OSPF into EIGRP can be re-learned by OSPF with a higher AD, causing suboptimal or looping paths.
• Shadow routes: A static route (AD 1) silently overrides a dynamically learned route that reflects actual topology changes.
• Asymmetric routing: Different routers in the same domain select different protocols for the same prefix because their AD comparisons resolve differently based on what each router has learned.

The default AD values you need to have memorized: Connected (0), Static (1), eBGP (20), EIGRP internal (90), OSPF (110), IS-IS (115), RIP (120), EIGRP external (170), iBGP (200).

The ones that cause the most production pain are the gap between EIGRP internal (90) and EIGRP external (170). A route redistributed into EIGRP from OSPF carries AD 170. If OSPF is still running on that segment with AD 110, OSPF wins, which is frequently not what you want.

Diagnosing the Problem: What to Look For

Start with show ip route and look at what's installed versus what you expect. The notation in brackets tells you exactly what you're dealing with: [AD/metric].

Router# show ip route 10.1.1.0
Routing entry for 10.1.1.0/24
  Known via "ospf 1", distance 110, metric 20
  Tag 0, type extern 2
  Last update from 192.168.1.2 on GigabitEthernet0/1, 00:03:42 ago
  Routing Descriptor Blocks:
  * 192.168.1.2, from 192.168.1.2, 00:03:42 ago, via GigabitEthernet0/1

If you expected this prefix to be installed via EIGRP but OSPF is winning, you know immediately that the EIGRP route has a higher AD (external, AD 170) losing to OSPF's 110. Confirm what EIGRP actually knows with:

Router# show ip eigrp topology 10.1.1.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.0.0.1) for 10.1.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160
  Descriptor Blocks:
  192.168.2.1 (GigabitEthernet0/0), from 192.168.2.1, Send flag is 0x0
      Composite metric is (28160/25600), route is External
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 200 microseconds

That "route is External" confirmation is your smoking gun. The EIGRP process knows about the prefix but it's carrying AD 170 and losing the AD comparison to OSPF at 110.

For BGP-related conflicts, use show bgp ipv4 unicast and check whether the route is showing a > (best) marker. An iBGP route at AD 200 will almost always lose to an IGP learning the same prefix, which is by design for route reflector environments but can surprise you during migrations.

Conflict Resolution Strategies

Adjusting AD Per Protocol

The blunt instrument approach: change the AD of the entire protocol process. Under EIGRP, you can do this with the distance command:

router eigrp 100
 distance eigrp 90 105

This sets internal EIGRP routes to AD 90 (unchanged) and external EIGRP routes to AD 105, which now beats OSPF's 110. Use this carefully. You're making a global change that affects all routes in that process.

For OSPF, you can adjust the distance globally or per source:

router ospf 1
 distance ospf external 115

This bumps OSPF external routes above IS-IS default but still below EIGRP external default. Every change here has downstream implications you need to think through for the full topology.

Adjusting AD Per Route Source (Targeted Approach)

The more surgical approach uses the distance command with an ACL to target specific prefixes or neighbors:

ip access-list standard OSPF_NEIGHBOR
 permit 192.168.1.2

router ospf 1
 distance 85 192.168.1.2 0.0.0.0 OSPF_NEIGHBOR

This sets OSPF routes learned from neighbor 192.168.1.2 to AD 85, making them preferred over EIGRP internal routes from that specific source. This level of granularity is what you want in production. Changing the entire protocol's AD is a sledgehammer; targeted distance commands are a scalpel.

Route Tagging to Prevent Redistribution Loops

AD conflicts during redistribution frequently cause routing loops. The standard fix is route tagging combined with deny statements in your redistribution route maps:

route-map OSPF_TO_EIGRP permit 10
 match ip address prefix-list OSPF_PREFIXES
 set tag 100

route-map EIGRP_TO_OSPF deny 10
 match tag 100

route-map EIGRP_TO_OSPF permit 20

Routes redistributed from OSPF into EIGRP get tag 100. When the EIGRP-to-OSPF redistribution policy runs, any route carrying tag 100 is dropped, preventing it from cycling back into OSPF. This doesn't fix the AD conflict itself, but it eliminates the loop that AD conflicts enable during two-way redistribution.

Verifying Your Fix

After making AD adjustments, always verify the routing table reflects your intent and that the change propagated correctly:

Router# show ip route 10.1.1.0
Routing entry for 10.1.1.0/24
  Known via "eigrp 100", distance 105, metric 28160

Follow up with show ip route summary to get a count of routes per protocol and confirm nothing unexpected dropped out of the table. Use debug ip routing cautiously in production; in a lab, it gives you real-time visibility into install and withdrawal events as you make changes.

For redistribution loop verification, run show ip route on boundary routers and trace whether any redistributed prefix has developed multiple entries with incrementally worsening metrics, which is the classic loop signature.

What's Next

With administrative distance conflicts in hand, the logical next step is digging into route redistribution mechanics in detail: how to configure two-way redistribution between EIGRP and OSPF, how metrics are translated across protocol boundaries, and how to build redistribute policies that scale without creating the loop conditions we covered here.

Tools and resources for this topic

• CCNP ENARSI 300-410 Official Cert Guide — The definitive ENARSI study resource by Raymond Lacoste. Covers advanced routing, services, and troubleshooting.