Field Guide · Networking
How a packet actually gets forwarded, hop by hop. Each device makes one local decision — "given this destination, what is the next hop and which interface does it leave by?" — and no single device knows the whole path. This guide is the deep-dive on that decision: longest-prefix match, the route-table fields, how ties break, and how to read a real routing table. It builds directly on the addressing math in Subnetting & CIDR.
Routing is per-hop and destination-based. A router does not compute an end-to-end path; it answers one question about the destination address and forwards, trusting the next device to do the same. Everything else — the table fields, the protocols, the tie-breakers — exists to make that single local decision correct and consistent.
Each device makes one decision per packet: given the destination IP, what is the next hop and the egress interface? It rewrites the frame and forwards. No device holds the full path — the source doesn't know the route, and each router knows only its own next step. This is why a traceroute is assembled hop by hop rather than read from any one place, and why an asymmetric path (out one way, back another) is normal rather than a fault.
The selection rule is Longest Prefix Match (LPM): among all entries that match the destination, the one with the longest prefix — the most specific — wins. LPM is applied first, before metric or administrative distance ever enter the picture.
A destination often matches several routes at once — a specific subnet, a larger aggregate, and the default route all cover it. The router picks the most specific match, always.
| Destination | Matches | Winner (longest prefix) | Next hop |
|---|---|---|---|
| 10.20.30.40 | /0, /8, /16, /24 | /24 | 10.1.1.3 |
| 10.20.99.1 | /0, /8, /16 | /16 | 10.1.1.2 |
| 10.5.0.1 | /0, /8 | /8 | 10.1.1.1 |
| 8.8.8.8 | /0 | /0 (default) | 192.168.1.1 |
Every route is a small record answering "for this destination, go where, out of what, and how much do I trust it?"
| Field | Meaning |
|---|---|
| Destination + prefix | The network and prefix length, e.g. 10.20.30.0/24. |
| Next hop / gateway | The IP of the next router — or "directly connected" if the destination is on a local subnet. |
| Egress interface | The interface the packet leaves through. |
| Metric | Cost used to break ties within the same routing source. |
| Administrative distance | A trust ranking used to break ties between different sources (a vendor concept, not an IP standard). |
| Source / protocol | How the route was learned: connected, static, OSPF, BGP, and so on. |
A next-hop gateway must itself be reachable on a directly-connected subnet — you cannot route to a next hop you have no way to reach. In particular, a host's default gateway must live on the host's own subnet. This is the routing-table echo of the local-vs-remote decision from Subnetting & CIDR: the very first hop has to be local.
| Type | Origin | Typical use |
|---|---|---|
| Directly connected | Auto-installed when an interface gets an IP and comes up | Reaching the local subnet |
| Static | Manually configured | Small or fixed topologies, and overrides |
| Default | A static or learned route for 0.0.0.0/0 (IPv4) or ::/0 (IPv6) | Catch-all when nothing more specific matches |
| Dynamic | Learned via a routing protocol (OSPF, BGP, EIGRP, RIP, IS-IS) | Large or changing topologies |
The default route has the shortest possible prefix, so by LPM it only wins when no more-specific route matches — it is the fallback, not a general answer.
Three tie-breakers apply in a fixed order — and getting the order right resolves most "why did it pick that route?" confusion:
Cisco IOS default administrative distances (verified against Cisco documentation; these are vendor defaults, configurable per device and occasionally varying by platform or release — confirm against current docs before relying on them for configuration):
| Source | Default AD | Source | Default AD |
|---|---|---|---|
| Connected interface | 0 | OSPF | 110 |
| Static route | 1 * | IS-IS | 115 |
| EIGRP summary route | 5 | RIP | 120 |
| External BGP (eBGP) | 20 | External EIGRP | 170 |
| Internal EIGRP | 90 | Internal BGP (iBGP) | 200 |
| IGRP | 100 | Unknown / unreachable | 255 |
* A static route pointing to a next-hop IP has AD 1; one pointing to an outgoing interface is treated as directly connected (AD 0). AD 255 means the source is not believed and the route is not installed.
The data-plane steps, in order: read the destination IP; look it up in the FIB by longest-prefix match to get a next-hop and egress interface; resolve the next hop's link-layer address (ARP for IPv4, NDP for IPv6); rewrite the frame's source and destination MAC and decrement the TTL (hop-limit in IPv6); transmit. No match and no default means drop the packet and return an ICMP unreachable; TTL reaching zero means drop and return ICMP time-exceeded — which is exactly how traceroute maps the path.
Two tables, two jobs. The RIB (Routing Information Base) is the control-plane table — every candidate route from every source, from which the best ones are selected. The FIB (Forwarding Information Base) is the data-plane table — the optimized, selected routes the hardware actually forwards with, at line rate.
The selection logic, table structure, and tie-breaking are identical. What differs is mechanical:
| Aspect | IPv4 | IPv6 |
|---|---|---|
| Default route | 0.0.0.0/0 | ::/0 |
| L2 address resolution | ARP | NDP (Neighbor Discovery) |
| Always-present route | — | link-local fe80::/10 |
| Hop counter field | TTL | Hop Limit |
On Cisco IOS, an entry like O 10.20.0.0/16 [110/20] via 10.1.1.2 reads as: O = learned via OSPF, 110 = administrative distance, 20 = metric, next hop 10.1.1.2. The bracket is always [AD/metric] — the two tie-breakers, side by side.
For the actual commands to view and test route tables on each platform — ip route and ip route get on Linux, route print on Windows, netstat -rn on macOS, show ip route and show ip cef on Cisco — see the Diagnostic Command Card, which groups them with the rest of the path-diagnosis toolkit. The most useful of these is the "which route would be chosen for this destination" query (ip route get, route -n get, show ip route ADDRESS): it answers the LPM question directly rather than making you read the whole table.
Per-hop, destination-based. Match the destination against the table; the longest prefix wins, decided before AD or metric. The default route (/0) wins only when nothing more specific matches.
1) Longest prefix · 2) Administrative distance (between sources, lower wins) · 3) Metric (within one protocol, lower wins). Common Cisco ADs: connected 0, static 1, eBGP 20, internal EIGRP 90, OSPF 110, RIP 120, iBGP 200 (vendor defaults, configurable).
FIB lookup by LPM → resolve next-hop MAC (ARP/NDP) → rewrite MACs, decrement TTL → transmit. IP src/dst stay constant end to end (until NAT); only MACs and TTL change per hop. No route → drop + ICMP unreachable.
RIB = all candidate routes (control plane); FIB = selected routes the hardware forwards with (data plane).
Longest-prefix match, the RIB/FIB split, and the forwarding steps are stable, standard behaviour. The Cisco administrative-distance values were verified against Cisco documentation, but administrative distance is a vendor concept, not an IP standard — the defaults are configurable per device and can vary by platform or release, so confirm them against current documentation before relying on them for configuration. One boundary worth stating: a route table decides reachability, not authorization — that a packet can be forwarded to a destination says nothing about whether it should be allowed there, which is the firewall's and zero trust's job, not routing's. Builds on Subnetting & CIDR (the prefix math); sits beneath "Networking — Follow the Packet"; and the commands live on the Diagnostic Command Card. Terms are in the Glossary; 00 · Start Here indexes the set.