Administrative Distance: The Complete Table, Proven on a Live Lab

When a router learns the same destination from two different routing protocols, it cannot install both. It has to pick a winner, and it does not use the metric to decide, because metrics from different protocols are not comparable (an OSPF cost of 11 and an EIGRP metric of 409600 measure completely different things). Instead it uses administrative distance: a fixed number ranking how much it trusts each source of routing information. Lower is more trusted.

This article gives you the complete default table and then proves the behaviour on a live lab: two iol-xe routers on CML running IOS XE 17.18.2, R1 and R2 back to back over 10.0.12.0/30, with R2 advertising 8.8.8.0/24 into OSPF and EIGRP at once. R1 installs the EIGRP copy, then reinstalls the same prefix via OSPF after a single command, with nothing about the topology changing. It is part of the wider guide to how a router builds and uses its routing table.

Two facts cause more confusion than everything else combined. AD is local to the router: it travels in no routing protocol, so your neighbours have no idea what yours is. And AD only breaks the tie between protocols, because inside one protocol every route carries the same distance and the metric decides it.

What administrative distance actually is

Administrative distance is a per-route-source trust value between 0 and 255. When two sources offer the same prefix with the same mask, the router installs the lower AD and leaves the other in its own protocol's database, unused but ready. AD is compared only after longest prefix match, a subtlety covered in how a router picks the most specific route. A /32 from RIP still beats a /24 from EIGRP, because prefix length is evaluated first and AD never gets a say. The full order for one destination is:

1. Longest prefix match. Nothing below this step can overturn it.
2. Lowest administrative distance. Among sources offering the identical prefix.
3. Lowest metric. Only ever between routes from the same source.
4. Equal cost, so install both, which is where uneven load sharing and CEF polarization come from.

AD never leaves the router

There is no field in an OSPF LSA, no TLV in an EIGRP update and no BGP path attribute that carries administrative distance. It is a local property of the receiving router, applied when a protocol offers a prefix to the RIB. There is therefore no such thing as an AD mismatch error: adjacencies do not fail over it and nothing logs a warning.

That makes every AD change a per-device item you have to apply consistently on every router that sees the prefix. Lower a static route's distance on R1 to force traffic down one link, forget the return path on R3, and you get asymmetric routing at best and a forwarding loop at worst. It only shows up in the data plane, which is why it pays to know how to spot a routing loop in a traceroute.

AD only breaks ties between protocols

If a router has four OSPF paths to the same prefix, all four have a distance of 110. There is no tie to break, so OSPF cost decides, and no amount of fiddling with distance under the OSPF process changes the outcome. The same goes for two EIGRP paths, and for two static routes to the same prefix, which both carry AD 1 and both install.

You can read both numbers off the table. In O 8.8.8.0/24 [110/11] via 10.0.12.2 the first bracketed number is the administrative distance and the second is the metric, a distinction that matters every time you work out what a line in the routing table is telling you. To steer between two paths inside one protocol you change the metric (OSPF cost, an EIGRP offset list), not the distance.

BGP looks like an exception, with eBGP at 20 and iBGP at 200, but it is not: BGP picks its own best path first and offers a single winner per prefix to the RIB, so those values are only ever weighed against other protocols. That two-stage process is why a prefix can sit in show ip bgp and never appear in the routing table.

The complete administrative distance table

These are the defaults on Cisco IOS and IOS XE. Memorise the common ones (0, 1, 90, 110, 120, and the two BGP values). The legacy entries are here because they still turn up in the docs and in exam questions.

Three deserve a note. eBGP sits at 20, below every IGP, so a router prefers a route from an external AS over its own internal routing, which is what you want at an internet edge. OSPF externals stay at 110 rather than taking the penalty EIGRP externals take at 170. And 255 does not mean "the worst route", it means "do not install this at all". One more that catches people: a static pointed at an outbound interface still has AD 1, even though the table prints it as directly connected.

Watching AD choose a winner, live

R2 owns 8.8.8.0/24 and advertises it into both OSPF area 0 and EIGRP AS 100, so R1 receives the identical prefix, same mask, same link, from two protocols at once. Ask R1 which one it installed:

R1# show ip route 8.8.8.0
Routing entry for 8.8.8.0/24
  Known via "eigrp 100", distance 90, metric 409600, type internal
  * 10.0.12.2, from 10.0.12.2, via Ethernet0/0

EIGRP won, because its internal AD of 90 is lower than OSPF's 110. The distance 90 is the whole explanation. The metric 409600 next to it played no part and is only ever compared against other EIGRP metrics. OSPF's copy is still in R1's link-state database, fully computed and valid; it just never got offered a slot in the table. That one line, Known via "<protocol>", distance <n>, answers almost every "why is my route not being used" question.

Flipping the winner with one command

To prove the decision is about trust and not about the network, change nothing physical and raise EIGRP's internal distance above OSPF's:

R1(config)# router eigrp 100
R1(config-router)#  distance eigrp 130 170     ! internal 130, external 170

R1# show ip route 8.8.8.0
Routing entry for 8.8.8.0/24
  Known via "ospf 1", distance 110, metric 11, type intra area
  * 10.0.12.2, from 2.2.2.2, via Ethernet0/0

Same destination, same next hop 10.0.12.2, same outgoing interface: every packet still leaves through the same port. All that changed is which process owns the entry, because EIGRP now offers the prefix at 130 and OSPF at 110.

Two details are worth pausing on. The metric went from 409600 to 11 for what is physically the same path, which is why cross-protocol metric comparison is meaningless. And from changed from 10.0.12.2 to 2.2.2.2, because EIGRP reports the neighbour's interface address while OSPF reports the advertising router ID (a source identifier, not a next hop).

The syntax matters more than you would expect. Under an EIGRP process a bare distance 130 is the address-based form and silently does nothing here: no error, no warning, no change. EIGRP wants distance eigrp <internal> <external>, and the reasoning behind that pair is in why EIGRP treats redistributed routes as less trustworthy.

What happens to the losing route

Nothing dramatic. The losing protocol keeps the prefix in its own database for as long as its neighbour advertises it; only RIB installation is contested. OSPF's 8.8.8.0/24 existed on R1 the whole time EIGRP owned the entry, which is why the swap above was immediate: no reconvergence, no new LSA, no neighbour event.

That is also what gives you deterministic failover when a protocol dies: EIGRP loses its adjacency, withdraws the prefix, and the OSPF copy drops straight in at 110. To see both copies, ask each protocol rather than the RIB:

show ip eigrp topology 8.8.8.0/24
show ip ospf database
show ip route 8.8.8.0

Floating static routes, the main practical use of AD

Every backup path design you build is this mechanism applied on purpose. A floating static is a static route given a distance high enough to lose to whatever normally carries the prefix: it stays out of the table while the primary is alive, and installs the moment that source withdraws.

! primary is learned via OSPF (AD 110); this only installs when OSPF's copy goes
ip route 10.0.20.0 255.255.255.0 192.0.2.1 200

! backup default route out a secondary circuit
ip route 0.0.0.0 0.0.0.0 198.51.100.1 250

The number is not arbitrary: it has to be higher than the AD of the source you are backing up, with headroom for another tier later (200 and 250 are the conventional choices). Never use 255, which means never install rather than install last.

Two ways a floating static fails to float. The first is the tie: two statics at the same distance do not back each other up, they both install and load share. The second is far more common in production. A static pointed at a next hop across an Ethernet segment or a metro circuit stays valid while the local interface is up, and that interface stays up even when the far end is dead, so the backup never activates. Condition the static on a reachability test rather than link state, which is what IP SLA with object tracking is for. Full syntax and the recursive lookup rules are in static routing on Cisco IOS XE.

Internal versus external distance inside one protocol

Several protocols carry more than one AD value, set together. EIGRP is the clearest case: routes learned natively get 90, routes redistributed in from elsewhere get 170, which is why the command above takes two numbers. The higher external distance biases every router toward a native path over a redistributed copy, reducing (but not eliminating) the chance of a redistribution loop. The equivalents elsewhere:

That last form is the one people trip over: distance plus a number, an address and a wildcard applies a distance to routes from specific neighbours, optionally narrowed by an ACL. It is also why the bare EIGRP distance 130 mistake is silent: the parser took a valid command, just not the one anyone intended.

Changing administrative distance, and when you should

You can override any default, but do it deliberately and document why. Three cases justify it: floating statics (above), a migration where old and new IGPs run in parallel and distance decides which one the network forwards on, and a redistribution boundary where raising the distance of routes from one neighbour stops a router preferring a redistributed copy of its own prefixes. A distance of 255 also suppresses a route entirely, a blunt alternative to a distribute list.

What does not justify it is a path preference problem inside one protocol: if both candidates come from OSPF, distance is not the lever, cost is.

AD is per-route, not per-protocol globally

A subtle point that trips up even experienced engineers: administrative distance is evaluated per prefix, not once for the whole protocol. OSPF does not "lose to EIGRP" across your network. For each destination the router compares only the sources that offered that prefix, so it is normal for one router to hold some prefixes via EIGRP, others via OSPF and others static, all at once. show ip route summary makes this concrete: the per-source counts add up to the whole table precisely because each prefix was won independently.

This is also why redistribution is dangerous. Redistribute OSPF into EIGRP and EIGRP back into OSPF and a prefix can arrive from two directions with different distances; if you have not planned them, the router may prefer the redistributed copy and start forwarding back toward the source. The internal and external split biases routers toward native routes but is not a complete safeguard, so with mutual redistribution, map the AD of every path a prefix can take. That is the first thing to check when routes vanish or loop after you turn redistribution on.

Metric versus administrative distance, do not confuse them

The two numbers in the bracket [110/11] get mixed up constantly, so nail the distinction:

What this was captured on

The lab is deliberately minimal, because the point is the decision and not the topology. Two iol-xe nodes on CML running IOS XE 17.18.2, R1 and R2 directly connected over 10.0.12.0/30, both running OSPF process 1 and EIGRP AS 100 across that link. R2 carries Loopback1 at 8.8.8.1/24 and advertises it into both. Both captures came from an on-box EEM applet on R1 logging show ip route 8.8.8.0 to syslog.

One build detail is worth stealing. OSPF advertises a loopback as a /32 host route whatever mask you configure, so left alone OSPF would carry 8.8.8.1/32 while EIGRP carried 8.8.8.0/24. Different prefixes never compete, and longest prefix match would hand every packet to the /32 regardless of distance. Adding ip ospf network point-to-point makes OSPF advertise the real /24 and puts the protocols in genuine contention: step one beating step two, every time.

Common mistakes and gotchas

• A bare distance 130 under EIGRP does nothing. That is the address-based form. Use distance eigrp <internal> <external> and verify with show ip route.
• Different prefix lengths never compete. If the two protocols advertise a /24 and a /32, AD is not involved. Check the mask first.
• Changing AD on one router only. Nothing exchanges distance, so a one-sided change produces asymmetric forwarding or a loop, silently.
• Expecting AD to pick between two paths in one protocol. They share a distance. Change the metric.
• Treating 255 as "last resort". It means never install, so a backup at 255 never activates.
• The floating static that never floats, because the primary stays valid while the local interface is up. Track reachability, not link state.

Key takeaways

• AD ranks route sources by trust, after longest prefix match and before metric, and lower wins: connected 0, static 1, eBGP 20, internal EIGRP 90, OSPF 110, IS-IS 115, RIP 120, external EIGRP 170, iBGP 200, 255 meaning never install.
• AD is local and appears in no protocol message, so every change must be made on every device that sees the prefix.
• AD only decides between protocols. Inside one, every route shares the distance and the metric decides, which is why distance will not steer traffic between two OSPF paths.
• show ip route <prefix> answers the question directly: Known via "<protocol>", distance <n> names the winning source and the number that won.
• Floating statics are this used deliberately: distance above the primary, 255 avoided, and a primary that can fail in a way the router notices.

For how the winning route is then handed to CEF and turned into forwarded packets, continue with the complete guide to routing on Cisco IOS XE.