TopicGems: How a Router Chooses Between Multiple Routes

I once bet a friend a coffee that I could tell him, without looking at his network once, which of his three internet connections a single ping would take.

He had a MikroTik box at home running a fiber line, a backup DSL line, and an LTE dongle plugged in "just in case," all pointed at the same destination — Google's DNS, 8.8.8.8. He assumed I'd guess wrong, because honestly, who keeps track of that on a home setup?

I won the coffee. Not because I'm psychic, but because a router never actually "guesses" which path to use. It runs every available route through a strict, boring, almost mechanical scoring process every single time — and once you know the rules of that process, predicting the outcome stops being a trick.

That's really what this whole topic comes down to. Multiple routes to the same place aren't a coin flip. They're a competition with very specific judges.

Meet the Three Contenders

Let's use a real setup to make this concrete, close to what I actually had in front of me during a home-lab session in GNS3 a while back.

Say a router has three separate ways to reach the same destination network, 10.20.0.0/24:

A static route someone typed in by hand, pointing out the fiber connection
An OSPF-learned route, pointing out a completely different link, learned automatically from a neighboring router
A default route (0.0.0.0/0), which technically covers that destination too, just far less precisely

All three are sitting in the router's memory at the same time. Only one of them gets used. Here's the order the router actually judges them in — and it's not the order most people assume.

Round One: Who's More Specific Wins First

Before anything else — before trust, before cost — the router asks one question: which route describes the destination most precisely?

This is called longest prefix match, and it always goes first, no exceptions. A route to 10.20.0.0/24 beats a route to 0.0.0.0/0 every time, even if the /24 route came from a source the router trusts less. Specificity beats everything else on the table.

In our example, the default route is eliminated immediately. It's not wrong, it's just too vague to compete once something more exact is available. It stays in the table as a fallback, quietly waiting for the day nothing more specific exists.

So now we're down to two: the static route and the OSPF route, both claiming the exact same /24.

Also Read: Why Devices Get 169.254 IPs

Round Two: Who Do You Trust More

This is where administrative distance comes in, and it's the part that trips up almost everyone I've ever explained this to — including me, the first time I ran into it live.

Administrative distance isn't about speed or cost at all. It's purely about trust. Every source a router can learn a route from gets a default trust score, and lower always wins:

Directly connected routes — trusted the most
Static routes — trusted a lot, since a human typed them
EIGRP internal routes — trusted fairly highly
OSPF routes — trusted less than static
RIP — trusted even less
Routes learned from an unknown or unverified source — trusted the least

In our scenario, the static route has an administrative distance of 1. OSPF sits at 110 by default. Lower wins, so the static route takes the job — regardless of what OSPF's actual path quality looks like.

And here's the uncomfortable truth: OSPF's path might genuinely be the better one. Faster link, less congestion, fewer hops. Doesn't matter. The router isn't judging quality yet. It's judging trust, and a manually configured static route out-trusts an automatically learned one by default, every time.

The Time the "Obviously Better" Route Lost

This is exactly what bit me during a client migration a while back, and I'll admit I didn't see it coming.

We'd set up OSPF between two sites as the primary path, genuinely the faster, lower-latency connection. But a static route had been added years earlier by someone else, pointing to the same destination through an old, slower VPN tunnel — supposedly just a leftover nobody thought to remove.

Traffic kept crawling through that old tunnel. I checked OSPF neighbor status, checked the metric, checked everything about "why is the good path not winning" — before realizing the good path was never even in the running. The static route's administrative distance beat it before metric ever got a vote.

Deleting one forgotten static route fixed what I'd been treating as a performance problem for two days. It was never a performance problem. It was a trust problem the router had been correctly solving the entire time — just not the way I expected.

Round Three: If Trust Is Tied, Cost Breaks It

If two competing routes come from the exact same source — say, two different OSPF paths to the same network — administrative distance is identical, so it can't break the tie. That's when metric takes over.

Metric is the actual "which path is better" number, and what it's made of depends on the protocol:

OSPF uses cost, based on interface bandwidth
EIGRP blends bandwidth and delay into a composite number
RIP just counts hops, plain and simple
BGP uses a whole separate set of attributes, since it's judging paths across entire networks, not just links

Lowest metric wins. This is the step most people picture when they imagine "the router picking the best route," but it's actually the last check, not the first — it only gets a say once specificity and trust have already been settled.

And If Even That's Tied?

Sometimes two paths really are dead equal — same source, same metric, both genuinely valid. Rather than picking arbitrarily, a lot of routers (and pretty much all serious enterprise gear) will use ECMP, Equal-Cost Multi-Path routing, and load-balance traffic across both.

This is where multi-WAN home routers and small business firewalls get interesting. A pfSense box or a MikroTik running two same-priced fiber lines doesn't necessarily pick one and ignore the other — it can split sessions across both, which is exactly what made my coffee bet slightly riskier than I let on. I already knew his static route was pinned to the fiber line specifically, or I'd have had to actually check.

Also Read: How Routers Know Where to Send Your Data

Watching It Happen for Yourself

You don't need enterprise gear to see this live. A few commands will show you exactly what a router "decided" and why:

show ip route on Cisco gear shows the active route, its source, and its administrative distance right in the output
ip route show on Linux or FRRouting does the same job, more compactly
traceroute (or tracert on Windows) shows you the path traffic is actually taking, hop by hop, which is the fastest way to confirm the router's choice matches what you expected
mtr is the same idea, but it keeps sampling continuously, which is genuinely useful if a route is flapping between two paths instead of settling on one

If you're the type who likes breaking things on purpose before they break themselves, spinning up two or three virtual routers in GNS3 or EVE-NG and deliberately configuring competing static and dynamic routes to the same destination is one of the more satisfying ways to actually watch administrative distance and metric fight it out, instead of just reading about it.

What This Means the Next Time Something Feels Off

If a network is quietly favoring a path you didn't expect, the fix seldom starts with "check the speed." It starts with checking the routing table and asking three questions in order — which route is most specific, which one is most trusted, and only then, which one is cheapest.

Most routing confusion I've run into on real networks traces back to skipping straight to that third question, assuming the router is optimizing for speed when it's actually still settling a trust argument two steps earlier. Once you check them in the right order, the router's choice usually stops looking random and starts looking exactly as predictable as it actually is.