Longest Prefix Match: How Routers Actually Choose Routes

Ask a room of engineers "which route wins?" and most reach straight for administrative distance. That is the wrong first answer. Before a router ever looks at AD or metric, it applies longest prefix match: given a destination IP, it forwards using the most specific route that contains that address, and a more specific prefix beats a less specific one no matter what protocol found it or how bad its metric is. Get this ordering right and a lot of confusing routing behavior suddenly makes sense. This article proves it on a live Cisco IOS XE router, and it is part of the IP Routing complete guide.

The rule in one sentence

When a packet needs forwarding, the router finds every route whose network contains the destination address, and among those it picks the one with the longest prefix (the largest number after the slash). Only if a single prefix length has multiple sources does administrative distance come into play, and only within one source does metric break the tie. Prefix length is the first filter, and it is absolute.

Two routes to the same block, on purpose

Router R1 has been given two overlapping routes to the 10.0.30.0 space: a /24 learned from OSPF, and a /25 configured as a static. Both are valid, both are in the table at the same time:

R1#show ip route | include 10.0.30
O        10.0.30.0/24 [110/11] via 10.0.13.2, 00:07:36, Ethernet0/2
S        10.0.30.0/25 [1/0] via 10.0.12.2

The /24 covers 10.0.30.0 through 10.0.30.255. The /25 covers only 10.0.30.0 through 10.0.30.127. They overlap: any address in the lower half is described by both routes. Notice the static (/25) has AD 1 and the OSPF route (/24) has AD 110. If AD were the deciding factor, the static would always win. It is not the deciding factor. Prefix length is.

Proving which route wins for which address

Take an address in the lower half, 10.0.30.1, and ask the router which route it resolves to:

R1#show ip route 10.0.30.1
Routing entry for 10.0.30.0/25
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.12.2
      Route metric is 0, traffic share count is 1

The router picked the /25. That address is covered by both routes, and the /25 is more specific, so it wins. Now take an address in the upper half, 10.0.30.200, which only the /24 covers:

R1#show ip route 10.0.30.200
Routing entry for 10.0.30.0/24
  Known via "ospf 1", distance 110, metric 11, type intra area
  Last update from 10.0.13.2 on Ethernet0/2, 00:07:37 ago
  Routing Descriptor Blocks:
  * 10.0.13.2, from 3.3.3.3, 00:07:37 ago, via Ethernet0/2

Same router, same table, same instant, but a different route because the /25 does not contain 10.0.30.200. The destination address decides which prefixes are even eligible, and then the longest eligible one wins. Two addresses in what looks like "the same subnet" take completely different next hops.

Confirming it in the forwarding plane

The routing table (RIB) is the control-plane view. The router actually forwards using CEF (the FIB). Check that CEF agrees, because forwarding is what a packet really experiences:

R1#show ip cef 10.0.30.1
10.0.30.0/25
  nexthop 10.0.12.2 Ethernet0/1

R1#show ip cef 10.0.30.200
10.0.30.0/24
  nexthop 10.0.13.2 Ethernet0/2

CEF confirms it: 10.0.30.1 forwards via 10.0.12.2 out Ethernet0/1 (the /25 static path), and 10.0.30.200 forwards via 10.0.13.2 out Ethernet0/2 (the /24 OSPF path). The control plane and forwarding plane match, which is what you want to see.

The clincher: a traceroute that takes the "wrong" path

If longest prefix match is really overriding administrative distance and metric, a packet to 10.0.30.1 should physically travel via the static's next hop (10.0.12.2, which is R2) rather than the direct OSPF path to R3. Trace it:

R1#traceroute 10.0.30.1 probe 1
Type escape sequence to abort.
Tracing the route to 10.0.30.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.12.2 1 msec
  2 10.0.23.2 3 msec

Two hops. The packet went to R2 first (10.0.12.2), then reached the destination via 10.0.23.2, exactly the longer path the /25 static points down. Compare that to the direct one-hop OSPF route the /24 would have used. And it still works end to end:

R1#ping 10.0.30.1
Sending 5, 100-byte ICMP Echos to 10.0.30.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms

This is the entire lesson made visible: the router chose a longer, higher-AD, higher-metric path purely because its prefix was more specific for that particular destination address.

Why this matters in real networks

Longest prefix match is not an exam curiosity; it is a working tool:

• Route summarization depends on it. A core router can advertise a single 10.0.0.0/8 while an access router advertises specific /24s, and traffic still finds the specific path because the /24 is longer than the /8.
• Traffic engineering uses it. Inject a more specific route to steer a subset of traffic down a preferred link without touching the broader routing design.
• Default routes are the shortest possible prefix (0.0.0.0/0 matches everything with length 0), which is exactly why the default is the route of last resort: any real route is more specific and beats it.
• Blackholing and RTBH (remotely triggered black hole filtering) work by injecting a very specific /32 that points to null, overriding any broader legitimate route for that one host.

How the router does the lookup so fast

You might wonder how a router compares a destination against thousands of routes for every single packet without falling over. It does not walk the table linearly. The forwarding table (CEF, the FIB) is organized as a tree structure (historically an mtrie) keyed by prefix, so a lookup descends bit by bit through the destination address and lands on the longest matching prefix in a bounded number of steps, regardless of table size. That is why an internet-edge router holding a full BGP table of nearly a million routes still forwards at line rate: longest prefix match is a hardware-optimized operation, not a loop. When you run show ip cef 10.0.30.1 and get an instant answer, you are reading the result of exactly that tree walk:

R1#show ip cef 10.0.30.1
10.0.30.0/25
  nexthop 10.0.12.2 Ethernet0/1

The takeaway for operators: the RIB (routing table) is where routes are chosen, but the FIB (CEF) is where the fast longest-prefix lookup happens on every packet. They should always agree; when they do not, you have found a real problem.

The ordering, start to finish

Put the three concepts in the sequence the router actually applies them:

A common source of confusion: overlapping does not mean conflicting

Beginners often see two overlapping routes in a table and assume one is a mistake. It is not. Overlapping prefixes are a normal, deliberate design: a broad route provides general reachability while a more specific route carves out an exception for part of that space. The routing table is perfectly happy holding a /8, a /24, and a /25 that all cover the same address, because longest prefix match guarantees each destination resolves to exactly one of them (the longest that matches). So when you see a specific static sitting alongside a broader dynamic route, that is usually intent, not error, and deleting the "extra" route can quietly break the traffic engineering it was performing.

Key takeaways

Longest prefix match runs first and it is absolute: the router forwards a packet using the most specific route that contains the destination address, regardless of administrative distance or metric. A /25 static beats a /24 OSPF route for addresses inside the /25, and the traceroute proves the packet really takes that path. Only after prefix length is settled does AD choose between sources, and only then does metric break the final tie. When you are troubleshooting "why did my traffic go there," check the prefix length before you blame the protocol, and confirm with show ip route <host> and show ip cef <host>. The full picture lives in the IP Routing complete guide.