Cisco IOS Path Selection: How a Router Chooses the Best Route

Articles · July 2026 · Ioannis (John) Konstas

A router's whole job comes down to one repeated question: for this packet, which way is best? The interesting part is that a router usually knows several ways to reach the same destination — one learned from EIGRP, another from OSPF, a static route someone typed by hand — and it has to pick exactly one to install and forward on. Cisco IOS resolves that with a strict, predictable order of tie-breakers. Once you know the order, routing tables stop being mysterious and troubleshooting becomes a matter of walking down the same checklist the router does.

Where routes come from

Before anything gets compared, routes have to enter the router from somewhere. There are three sources: connected routes (the subnets on the router's own live interfaces), static routes (manually configured), and dynamic routes learned from a routing protocol. Each dynamic protocol runs its own algorithm to work out candidate paths — EIGRP uses DUAL, OSPF runs SPF (Dijkstra) over a link-state database, and BGP weighs a chain of path attributes. They all feed their best candidates into the same selection funnel.

Step 1: Longest prefix match wins

The very first thing IOS looks at is not the protocol or the metric — it's specificity. Given several routes that could carry a packet, the one with the longest matching prefix always wins, regardless of where it was learned. Consider three routes to overlapping space:

10.0.0.0/8
10.10.0.0/16
10.10.10.0/24

A packet destined for 10.10.10.50 matches all three, but IOS forwards it using 10.10.10.0/24 because that /24 is the most specific match. This rule sits above everything else, and it's the lever behind most traffic engineering: advertise a more specific prefix and you pull traffic toward it, no matter what the less specific routes say.

Step 2: Administrative Distance breaks protocol ties

When two different sources offer a route to the same prefix at the same length, IOS can't compare their metrics — an OSPF cost and an EIGRP composite metric aren't the same unit. So it falls back to Administrative Distance (AD), a trust ranking of the source itself. Lower AD means more trusted, and the lower AD wins.

So if EIGRP (AD 90) and OSPF (AD 110) both offer 10.1.1.0/24, the EIGRP route is installed — not because EIGRP found a shorter path, but because IOS trusts it more by default. That default is deliberate and tunable: you can override AD per route to steer this decision when you want the "less trusted" protocol to win. Two values at the ends of the table are worth calling out: an AD of 5 belongs to EIGRP summary routes (more on those below), and an AD of 255 means "do not trust this source at all" — a route tagged 255 is never installed in the table.

Step 3: Metric decides within one protocol

Only when the two candidates come from the same protocol does the metric finally matter — now the units are comparable. IOS installs the route with the lowest metric. What "metric" means depends on the protocol: EIGRP builds a composite from bandwidth and delay (with reliability and load available but off by default), while OSPF derives a cost primarily from interface bandwidth. Same protocol, lowest metric, done.

The edge case worth being honest about: two instances of the same protocol

This is the corner of IOS path selection that the standard references gloss over — they walk you through prefix length, Administrative Distance, and metric, then stop. You can run more than one instance of a protocol on the same router (two EIGRP autonomous systems, or two OSPF processes), and it's fair to ask what happens when both instances learn the same prefix at the same Administrative Distance.

router eigrp 5     ! learns 10.1.1.0/24
router eigrp 7     ! also learns 10.1.1.0/24  (same AD 90)

router ospf 5      ! learns 192.168.1.0/24
router ospf 7      ! also learns 192.168.1.0/24  (same AD 110)

You'll see it claimed — in a lot of study material — that IOS simply prefers the lower autonomous-system number or the lower process ID. Be careful with that: it is not documented, deterministic Cisco behavior. The two instances maintain separate topologies, so their metrics aren't comparable, and with the Administrative Distance already tied there is no published rule that "the lower number wins." In practice the route that is already installed tends to stay, which makes the outcome depend on timing and install order rather than on the instance number.

So the genuinely useful, field-tested takeaway isn't a tie-break rule — it's this: never design around this case. If you're running overlapping EIGRP ASes or OSPF processes that both carry the same prefix, don't trust an implicit winner. Make the decision explicit — tune the Administrative Distance, or redistribute deliberately — so the router installs the route you chose, not the one it happened to see first.

When routes are truly equal: load balancing

Sometimes two paths survive every comparison as genuine equals. Rather than discard one, IOS installs both and shares traffic across them — equal-cost multipath (ECMP):

10.1.1.0/24 via GigabitEthernet0/0
10.1.1.0/24 via GigabitEthernet0/1
! equal cost -> both installed, traffic balanced

How many equal paths IOS will install is capped by maximum-paths under the routing process. Raise it to spread load across more links; the default varies by platform and protocol, so set it explicitly when the design depends on it.

RIB and FIB: deciding versus forwarding

The output of all this comparison is the Routing Information Base (RIB) — the routing table you see with show ip route. The RIB holds the winning routes with their next hops and exit interfaces. But the RIB is a control-plane structure; it's not what forwards packets at line rate.

From the RIB, IOS builds the Forwarding Information Base (FIB) — the CEF forwarding table, pre-computed and optimized so the data plane can look up a destination and forward it in hardware without re-running the decision logic per packet. The clean way to hold the two apart: the RIB decides, the FIB forwards.

Routing protocols  (EIGRP / OSPF / BGP, static, connected)
        ↓
Candidate routes
        ↓
Best-route selection   (prefix length → AD → metric → instance)
        ↓
RIB    (show ip route)      ← the decision
        ↓
FIB    (CEF table)          ← the forwarding
        ↓
Packet out the interface

Turning the rules into traffic engineering

Because longest-prefix-match outranks everything, the most reliable way to steer traffic is to advertise something more specific. A neighbor announcing 192.168.0.0/16 carries the whole block, but announce 192.168.10.0/24 from a second path and every packet to 192.168.10.x follows the /24 — the /16 never gets a say for that range. This one behavior underpins ISP traffic engineering, multi-homing, and inbound path control. It's also why route filtering and prefix-length policy matter so much at the edge: a single more-specific advertisement, yours or someone else's, quietly rewrites where traffic goes.

The other lever: EIGRP summary routes and AD 5

If advertising a more specific prefix is how you pull traffic toward a path, summarization is the opposite move — collapsing many prefixes into one advertisement to shrink routing tables and stop local instability from rippling across the network. EIGRP has a neat, and slightly under-explained, way of handling this. When you configure a manual summary on an interface:

interface GigabitEthernet0/0
 ip summary-address eigrp 10 172.16.0.0 255.255.0.0

EIGRP does two things. It advertises the single 172.16.0.0/16 summary to neighbors — and locally it installs a summary route to Null0 with Administrative Distance 5. That AD 5 (from the table above) makes the summary route very trusted — more trusted than internal EIGRP itself — so it stays put in the table.

The Null0 part is the clever bit. It's a discard route: any packet that matches the /16 summary but has no more-specific real route to land on gets dropped instead of forwarded. That prevents a loop — without it, traffic for a non-existent subnet inside the summarized block could bounce back and forth between the summarizing router and its upstream. And it all coexists cleanly with longest-prefix-match: real destinations inside the block still match their more-specific routes and forward normally; only the gaps — addresses that don't actually exist — fall through to Null0 and die quietly. Summary for advertisement efficiency, longest match for real forwarding, Null0 plus AD 5 for loop safety.

The mental model to keep

• Specificity first — longest prefix match beats everything, every time.
• Then trust — Administrative Distance decides between different protocols.
• Then cost — metric decides within one protocol.
• Two instances of one protocol is undefined — don't rely on a lowest-AS/PID tie-break; control it explicitly with AD or redistribution.
• RIB decides, FIB forwards — control plane chooses, data plane executes in hardware.

Path selection isn't guesswork — it's the same checklist run in the same order every time: most specific prefix, lowest Administrative Distance, lowest metric. Learn that order and any routing table will tell you exactly why a packet went the way it did — and where the order runs out, make the decision explicit rather than trusting the router to break the tie for you.

← All articles

Research and direction by Ioannis (John) Konstas; compiled and finalized with AI assistance.