Forwarding chooses the most specific matching prefix

A destination matches a prefix when its first p bits equal that prefix's p fixed bits. The default IPv4 route 0.0.0.0/0 fixes no bits and therefore matches every IPv4 destination. A /32 fixes all 32 bits and matches exactly one address. Between them, overlapping routes form a hierarchy. Prefix length measures specificity; the numerical value of an address and the order in which routes appear in a printed listing do not define the winner.

Suppose the installed table contains a default via A, 198.51.100.0/24 via B, and 198.51.100.128/25 via C. Destination 198.51.100.170 matches all three, so it follows C. Destination 198.51.100.70 matches the default and /24, so it follows B. This conclusion assumes ordinary destination-based unicast forwarding in the relevant table. Policy routing can first select another table or rule context; record that context before applying the same lookup reasoning.

Routing protocols and local configuration can offer several candidate paths for the same prefix. Their selection rules determine which paths become usable forwarding entries, possibly including equal-cost next hops. Longest-prefix matching then operates across the installed prefixes for a packet's destination. A lower metric attached to a /16 does not override an installed matching /24 merely because its number is smaller. Comparing those metrics across specificity levels confuses two different stages.

A next hop may itself require recursive route resolution and a reachable adjacency. A control-plane route shown as selected is therefore insufficient evidence that a packet leaves the expected interface. Check the actual forwarding entry, its resolved next hop, and the neighbor state. Hardware and software forwarding views can also differ during updates. Diagnosing a reported route without checking its installation and resolution can miss the exact layer where forwarding stopped.

An aggregate advertisement claims reachability for its whole prefix, although the advertiser may have only some more-specific destinations active. A discard route for the aggregate can deliberately stop unmatched traffic from looping back toward a default route. The discard is safe only in the sense of preventing that forwarding loop; it does not make missing destinations reachable. An accidentally installed discard with a longer matching prefix will also win over a valid less-specific route, so inspect both successful and failing addresses.

The probability lab illustrates a testing hazard rather than performing route lookup. Interpret p as the fraction of independently, uniformly sampled destination addresses that fall in a failing child prefix, and n as the number of tests. A failed /25 inside a /24 gives p=0.5 under that synthetic sampling rule. Predict the zero-failure bar as n increases. Production traffic is rarely uniform or independent, so explicitly probe each advertised exception and aggregate gap instead of treating random success as proof of a complete route table.