Every host on your network makes a routing decision before it sends anything. It is a single comparison — is the destination inside my subnet? — and it explains most of the behavior people find mysterious: why the printer works but the internet does not, why a ping to a nearby building crosses the core twice, why "no route to host" and "request timed out" mean different things.

The host's only routing decision

Take a laptop at 10.40.12.57/21, gateway 10.40.8.1.

  • Destination 10.40.14.20: inside 10.40.8.0/21. Send directly. ARP for the destination, put the destination's MAC on the frame.
  • Destination 203.0.113.10: outside. Send to the gateway. ARP for 10.40.8.1, put the gateway's MAC on the frame, and leave the destination IP untouched.

That last detail trips people up: the frame is addressed to the router, but the packet inside is addressed to the server. Layer 2 delivers hop by hop; layer 3 addresses stay end to end. A router receives the frame because of its MAC, then looks at the IP header to decide what to do next.

A host hands off-subnet traffic to its gateway; each router repeats the same decision.

What is in a routing table

A router (or a layer 3 switch) keeps a table of destinations, each with a next hop and an interface:

Destination Mask Next hop Interface
10.40.8.0 /21 directly connected vlan104
10.40.60.0 /22 10.40.0.2 vlan100
10.0.0.0 /8 10.40.0.2 vlan100
0.0.0.0 /0 198.51.100.1 wan1

Reading a table is a matter of reading masks. The router compares the destination address against every entry and picks the most specific match — the one with the longest prefix. A packet to 10.40.60.55 matches both /22 and /8; the /22 wins because it is more specific. A packet to 203.0.113.10 matches only 0.0.0.0/0, the default route.

Longest prefix match, not first match. Order in the table does not matter for routing (it does matter for firewall policy, which is why the two get confused). The most specific route always wins.

The default route is a promise

0.0.0.0/0 means "everything I have not matched, send here." It is how a host or a small router participates in the internet without knowing a single public prefix. When the default route is missing, only local traffic works; when it points at a dead next hop, everything off-subnet fails at once.

Hop by hop, not end to end

A packet from a Chromebook to a web server does not take one decision. It takes one decision per router.

  1. The Chromebook picks its gateway.
  2. The access switch delivers the frame to the gateway.
  3. The core router looks up the destination and forwards to the firewall.
  4. The firewall NATs the source and forwards to the ISP.
  5. Each ISP router repeats the lookup until the packet reaches the destination network.

TTL exists to bound this. Every router decrements it, and at zero the packet is discarded with an ICMP time-exceeded message. That mechanism is what traceroute exploits: it sends packets with deliberately small TTLs and listens for the replies, which is why it can map a path without any cooperation from the destination.

The return path matters as much as the outbound one

Routing is usually asymmetric in configuration even when it is symmetric in topology. A packet can leave through the firewall and return through a different link. If the return path has no route back, or if a stateful device never saw the outbound packet, the reply is dropped.

Symptoms of a return-path problem:

  • Outbound connections time out, but the server logs show the request arriving.
  • Pings work in one direction only.
  • Some destinations work, others do not, and the difference is which ISP they are behind.

Worked example: two buildings and the internet

A student device at 10.10.40.55/21, gateway 10.10.40.1, wants three things:

Destination Match Path
10.10.41.20 local /21 direct, ARP, no router involved
10.40.60.9 (other campus) 10.0.0.0/8 via core gateway → core → campus router
203.0.113.10 0.0.0.0/0 gateway → core → firewall → ISP

Three destinations, three different paths, all decided by the same rule. The student notices nothing.

"No route to host" is not the same as "timed out"

"No route to host" means a device actively reported that it cannot reach the destination — usually a missing route or an ICMP unreachable from a router. "Request timed out" means silence: the packet left and nothing came back. The first is a routing statement; the second is usually a firewall, a return path, or a dead host. Treating them as the same symptom sends you looking in the wrong place.

What breaks in production

  • No default route. Local traffic works, everything else fails. Often caused by a typo in the next hop or a default route that was never redistributed into the routing protocol.
  • Asymmetric return. Outbound works, replies vanish. Common when two links to the internet exist and only one has a state table.
  • Overlapping subnets. Two sites using 10.10.40.0/24 cannot both be routed; the more specific route wins and one site becomes unreachable from the other.
  • A gateway that is not on the subnet. The host cannot ARP for it, so it never sends the frame. Everything reports "no route to host" while the router is healthy.
  • Proxy ARP hiding a mask error. A router answers ARP for off-subnet hosts, so a host with the wrong mask still reaches its neighbors — until it does not, usually after a topology change.

Checklist

  1. Every host has a gateway that is inside its own subnet.
  2. Every router has a default route, and you know its next hop by name.
  3. You can read a routing table and identify the longest prefix match for a given address.
  4. Return paths are symmetric, or the stateful device is in both directions.
  5. You can tell "no route to host" from "request timed out" without opening a packet capture.

Next

Routing gets a packet to a server by name only if something translated that name first, and every address came from somewhere. Continue with DHCP and DNS: The Two Services Everything Assumes.

  • Routing
  • Gateway
  • ICMP
  • Fundamentals