13. Routing: tables, longest-prefix match, and default routes

13.1 The routing table

Every IP host — not just routers — has a routing table. Sending a packet = looking up its destination and getting (next hop, egress interface, source IP).

$ ip route
default via 192.168.1.1 dev wlan0 proto dhcp metric 600
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.50 metric 600

Read each line as: "to reach <prefix>, send via <next hop> out <dev>."

• scope link / no via → destination is directly connected; ARP for the destination itself.
• via X → send to gateway X (ARP for X).
• default = 0.0.0.0/0 → matches everything not matched more specifically.

13.2 Longest-prefix match (LPM)

When multiple routes match, the one with the longest prefix (most specific) wins, regardless of order or metric.

Routes:            Packet to 10.1.2.3 matches:
  0.0.0.0/0          yes  (/0)
  10.0.0.0/8         yes  (/8)
  10.1.0.0/16        yes  (/16)
  10.1.2.0/24        yes  (/24)   <-- WINNER (longest)

Metric/administrative distance only breaks ties among routes of equal prefix length (or chooses between routing protocols). This is why a /32 "host route" always beats a subnet route, and why a leaked more-specific BGP prefix hijacks traffic (Ch. 50).

13.3 How routers learn routes

Link-state (OSPF/IS-IS): every router floods its local link info; all build an identical map; each runs Dijkstra for shortest paths. Fast reconvergence, scales to thousands of routers per area.

13.4 Forwarding vs routing (control plane vs data plane)

• Control plane: the protocols (BGP/OSPF) that compute the best paths → build the RIB (Routing Information Base). Runs on the CPU. Slow, complex.
• Data plane: the FIB (Forwarding Information Base), a compiled copy of the best routes pushed into hardware (TCAM/ASIC) that forwards packets at line rate. When people say "the router does 10 Gbit/s," they mean the FIB.

13.5 Policy routing (Linux)

Beyond destination-based routing, Linux supports multiple tables chosen by ip rule (source address, fwmark, interface, ToS). Used for multi-homing, VPN split tunneling, and "traffic from container X goes out uplink 2."

ip rule add from 192.168.50.0/24 table 100
ip route add default via 10.0.0.1 dev eth1 table 100

13.6 Asymmetric routing and its traps

Packets can take path A→B outbound and B→A return on a different path. That's normal on the internet. It breaks:

• Stateful firewalls that see only one direction → drop the "unsolicited" replies.
• Linux reverse-path filtering (rp_filter=1): drops a packet if the reply wouldn't go back out the interface it arrived on. Set rp_filter=2 (loose) for multi-homed hosts.

13.7 War story

A dual-homed server (two ISPs) worked for outbound but external users could reach it only via ISP-A. Replies to ISP-B-sourced requests left via the default route (ISP-A); ISP-A's edge dropped packets with an ISP-B source IP (BCP 38 anti- spoofing). Fix: policy routing — mark connections by inbound interface and route replies back the same way. Lesson: on multi-homed hosts, the return path must match the request path, or stateful devices and anti-spoofing filters will silently eat your traffic.

Try it yourself

ip route                              # main table
ip route get 1.1.1.1                  # exact decision for one destination
ip rule                               # policy rules
ip route show table all               # every table
mtr -rwzbc100 example.com             # combined traceroute + loss/latency per hop
traceroute -n example.com             # UDP probes; add -I for ICMP, -T for TCP