Ask a network engineer why a packet took a particular path and the honest answer is usually "the routing table said so." The table is not a diagram of the network. It is a list of claims, each with a source, a preference, and a cost — and the router believes the most specific claim it has.

This series is about the smallest possible routing design: static routes between a handful of sites. It starts with the table, because every static route you add is a line in it, and every routing failure is a line that is wrong, missing, or shadowed.

Three ways a route gets in

A router builds its table from three sources:

Source Where it comes from Default distance (Cisco) Changes when
Connected An interface with an IP and no shutdown 0 Interface up/down
Static You typed it 1 You edit it
Dynamic A routing protocol OSPF 110, EIGRP 90, BGP 20/200 Topology changes

The distance is a preference, not a measurement. Lower wins. It only matters when two sources offer the same prefix — OSPF and a static route to 10.50.0.0/16 compete; a static /16 and a dynamic /24 do not.

UniFi hides most of this. Its gateway runs a Linux routing stack, and what you see in Settings → Routing → Static Routes is a small subset of the kernel table. That is fine for a static design, and it is also why the table is short enough to read.

The same table answers four different destinations, by prefix length.

Longest prefix wins, always

Take this table:

10.40.8.0/21     connected   vlan104
10.0.0.0/8       static      10.40.0.2
10.50.0.0/16     static      10.0.0.9
0.0.0.0/0        static      198.51.100.1

Four destinations:

Destination Matches Chosen Why
10.40.12.57 /21 only connected Directly attached
10.40.60.9 /8 static via core Only match
10.50.7.20 /16 and /8 /16 Longer prefix
203.0.113.10 /0 default Nothing else matches

The order of the lines is irrelevant. The router does not read top to bottom; it finds every match and picks the longest mask. This is the single most common misconception about routing tables, and it is why "I put the more specific route first" is not a thing.

Distance breaks ties, prefix length breaks silence

Two routes to the same prefix from different sources: lowest distance wins. Two routes to different prefixes that both match: longest prefix wins, and distance never enters the decision. Mixing the two rules up produces routing designs that work by accident.

The default route is a claim about everything

0.0.0.0/0 matches every address, and it is the least specific possible claim. It exists so a router does not need to know the entire internet.

On a campus gateway the default route points at the ISP. On a building router it points at the core. On the new elementary campus it will point back at the district over whatever link you build, which is the design decision the rest of this series is about.

Worked example: what the district gateway actually does

A packet from a student Chromebook at 10.40.12.57 heading to 10.50.7.20:

  1. The host compares against its own /21: not local, so it sends to its gateway.
  2. The gateway looks up 10.50.7.20 and finds the /16 static route.
  3. The next hop is 10.0.0.9, which is itself reachable through the connected 10.0.0.0/24.
  4. The gateway ARPs for 10.0.0.9, forwards, and the core repeats the lookup.

Two lookups happened: one for the destination, one for the next hop. That second lookup is recursive and it is where static designs break — a route is only as good as the reachability of its next hop.

What breaks in production

  • A shadowed route. A /16 covering the new campus is installed before the /24 for its server VLAN, so the specific traffic goes to the wrong next hop. Symptom: one subnet unreachable while its neighbors work.
  • A next hop that is not on a connected network. The router cannot ARP for it, so the route never becomes active. Some platforms accept the config silently and simply never use it.
  • Equal distances. Two static routes to the same prefix with the same distance cause per-packet or per-flow load balancing, which is rarely what was intended and looks like intermittent packet loss.
  • A stale route after a redesign. The subnet moved; the static route did not. Traffic black-holes into a next hop that no longer has that network behind it.
  • Reading the table on the wrong device. The host, the access switch, the core, and the firewall each have a table. "It has a route" is meaningless without saying where.

Checklist

  1. You can name every source of every route on your gateway.
  2. You know which prefix each site's traffic matches, and why.
  3. Every static route's next hop is reachable through a connected route.
  4. No two static routes to the same prefix share a distance.
  5. You can predict the lookup result for a destination before typing traceroute.

Next

The table is the map. Continue with Static Routes: Right Tool, Common Trap to decide when a line in that table is the correct design and when it is technical debt.

  • Routing
  • Static Routes
  • Layer 3
  • Fundamentals