The Routing Table and Longest-Prefix Match
Every device that speaks IP — a laptop, a phone, a container, a core router — keeps a routing table: a list of destination prefixes, each paired with where to send packets headed there. For every packet, the device runs one lookup against this table, picks a single winning route, and forwards toward the next hop it names. There is no global map and no end-to-end plan; there is only this local table answering one question, packet after packet.
The rule that picks the winner is longest-prefix match: among all entries whose prefix contains the destination address, the one with the most specific prefix — the longest mask — wins. A /32 beats a /24 beats a /0. The catch-all default route 0.0.0.0/0 matches everything but is the least specific, so it only wins when nothing more specific does. That single rule, applied consistently, explains nearly all routing behavior you will ever debug.
The Routing Table
A routing-table entry has four parts that matter: the destination prefix (an address plus a mask length, like 10.0.0.0/24), the next-hop (the IP of the neighboring router to hand the packet to, or "directly connected" if the destination is on a local wire), the outgoing interface (which NIC the frame leaves by), and a metric (a tie-breaker cost when two routes have the same prefix length). The lookup matches on the prefix; the next-hop and interface tell the device what to physically do once a route wins.
The table is not the same thing as the database the routing protocols build. The full set of candidate routes a router has learned lives in the RIB (Routing Information Base); the lean, optimized copy the forwarding hardware actually consults at line rate is the FIB (Forwarding Information Base). On a host the distinction blurs, but on a router it is the difference between control plane and data plane — the RIB decides, the FIB forwards.
Longest-Prefix Match
When a destination matches several routes at once, prefix length alone decides — not the order entries appear and not their metric, until prefix lengths tie. Say the table holds 10.0.0.0/8 via router A and 10.1.2.0/24 via router B. A packet to 10.1.2.55 matches both, but the /24 is more specific, so it wins and the packet goes to B. A packet to 10.9.9.9 matches only the /8, so it goes to A. The more specific route always carves its own range out of the broader one.
This is why a single specific route can override the default without touching it. You can leave 0.0.0.0/0 pointing at your normal gateway and add one /32 host route to send just one destination out a different path — the /32 wins for that one address and the default still catches everything else. Metric only enters the picture as a tie-breaker between two routes of equal prefix length; it never lets a shorter prefix beat a longer one.
The Default Route
The default route, 0.0.0.0/0, is the route of last resort. Its mask length is zero, so it matches every possible address but loses to any other matching entry — it is the answer the table gives only when it has no more specific one. On a typical host this is the single route that matters: the host knows its own subnet directly and sends literally everything else to its default gateway. A device with no default route and no matching specific route simply drops the packet and, if asked, returns "network unreachable."
A default route is convenient and dangerous in the same breath. It guarantees the device always has somewhere to send unknown traffic, which is exactly what you want at a network edge. But point it at the wrong next-hop, or point it at a router that itself has no path onward, and you have built a black hole — packets vanish toward a device that quietly discards them, with no error and no clue at the source.
Reading a Real Table
On Linux, ip route prints the table, and ip route get shows exactly which route the kernel would pick for one address — the single fastest way to confirm a longest-prefix decision instead of reasoning about it. Connected routes (the subnets your interfaces sit on) appear with a scope link and no via, because their destinations need no next-hop; learned and static routes carry a via pointing at a gateway.
# the full table: one default, two connected subnets, one specific route ip route # default via 10.0.0.1 dev eth0 <- 0.0.0.0/0, route of last resort # 10.0.0.0/24 dev eth0 scope link <- directly connected # 10.0.5.0/24 dev eth1 scope link <- directly connected # 192.168.9.0/24 via 10.0.0.2 dev eth0 <- learned/static, more specific # ask the kernel which route wins for one destination ip route get 192.168.9.40 # 192.168.9.40 via 10.0.0.2 dev eth0 <- the /24 beat the default ip route get 8.8.8.8 # 8.8.8.8 via 10.0.0.1 dev eth0 <- nothing specific, default wins
Connected routes appear automatically the moment you assign an address to an interface — the kernel knows that subnet is on the wire, with no next-hop. They are the most trusted entries and need no protocol. Static routes are typed in by an operator and never change on their own; they are predictable but do not react when a link dies.
Dynamic routes are learned by a routing protocol (OSPF, BGP) and updated as the topology shifts. Among entries for the same destination, precedence is by prefix length first, then by metric or administrative distance — so a more specific dynamic route still beats a broader connected one, even though connected routes are otherwise the most authoritative.
- Assuming routes are checked top-to-bottom like a firewall ruleset. The table is not first-match; it is most-specific-match. Adding a broad route "above" a specific one changes nothing — the longer prefix still wins regardless of order.
- Forgetting the return route. You add a route so host A can reach subnet B, traffic flows out, and nothing comes back — because B has no route back to A. Reachability is two one-way decisions, and a missing return route gives you silent one-way connectivity.
- Installing a route that is too broad and black-holing traffic. A 10.0.0.0/8 pointed at a router that only actually reaches 10.1.0.0/16 swallows every other 10.x destination into a path that drops it.
- Confusing the RIB with the FIB when a route "exists" but traffic still fails. A route present in the RIB that lost selection never made it into the FIB, so the forwarding plane never uses it — check what was actually installed, not just what was learned.
- Relying on a default route at a transit router that should carry specific routes. A default in the core can mask a missing real route, sending traffic toward a device that has nowhere to forward it onward.
- Use ip route get <dest> to confirm the winning route for a specific address rather than eyeballing the table — it reports the exact longest-prefix decision the kernel will make, including the chosen interface and source.
- Verify the return path explicitly whenever you add a route, by checking the destination's own table for a route back to your source. Treat reachability as two directions, not one.
- Prefer specific routes over relying on a broad catch-all inside a network you control, so traffic to a destination with no real path fails loudly as unreachable instead of disappearing into a black hole.
- Keep the default route at edges and stub devices, not in the transit core where every prefix should be explicitly known — a default in the core hides missing routes.
- Inspect the installed FIB (for example with ip route show table all or platform CEF commands) when a learned route is not taking effect, since selection between competing routes happens before forwarding ever sees them.
Knowledge Check
A table holds 10.0.0.0/8 via router A, 10.1.0.0/16 via router B, and 0.0.0.0/0 via router C. Where does a packet to 10.1.2.3 go?
- Router B, because
/16is the most specific matching prefix - Router A, because
/8covers the whole10.xrange - Router C, since the default route is always checked first before the others
- Whichever route was added to the table earliest
What does the default route 0.0.0.0/0 actually do in a routing table?
- Matches any destination but wins only when no more specific route matches
- Takes priority over all other routes in the table as the single highest-priority entry
- Matches only addresses on the device's own local subnet
- Drops any packet whose destination is unknown to the device
You add a route so host A reaches subnet B, traffic leaves A, but no replies ever return. What is the most likely cause?
- Subnet B has no route back to A, so replies are dropped on the return path
- Longest-prefix match randomly discards some of the otherwise matching packets
- The default route on A is blocking the outbound packets entirely
- Host A is missing a connected route to its own local subnet
You got correct