How a Host Decides Where to Send a Packet
- Every host has a routing table, usually two or three rows: a connected route for its own subnet and a default route (
0.0.0.0/0) via the default gateway. - The decision is the same longest-prefix lookup a router does: if the destination matches the connected route, it is local; otherwise it falls through to the default route and is remote.
- Local: ARP for the destination's IP and put its MAC in the frame. Remote: ARP for the gateway's IP and put the gateway's MAC in the frame, while the IP header still names the final destination.
- Per hop, the MACs are rewritten, TTL drops by 1 and the header checksum is recomputed. The IP addresses stay the same end to end, except where a NAT rewrites the source.
- "Local network works, internet does not" almost always means the gateway, the default route, or the mask is wrong.
Mental model
You have a letter to send. If the recipient lives on your street, you walk it to their door yourself. If they live anywhere else, you do not try to find the house: you drop it at the post office and write the full address on the envelope. The post office is the only place you need to know how to reach, and "anywhere else" is one rule, not a list of every street.
Where it breaks: a letter keeps one envelope. A packet gets a new outer envelope (the frame's MAC addresses) at every hop, while the inner address (the IP header) is read and left alone. And you can be wrong about "my street": if your mask is wrong, you walk to a door that is not on your street.
Every host runs the same longest-prefix lookup a router does, just over a tiny table. It is like a service client with one explicit rule ("calls to the internal registry go direct") and one catch-all ("everything else goes through the API gateway"). The gateway is a next hop, not the destination: the packet's destination field never changes, only who you hand it to.
Where it breaks: an API gateway terminates your request and makes a new one. A router does not: it forwards the same IP packet (TTL and checksum aside), so the original destination address survives every hop.
How it works
The host routing table
Textbooks teach "the router decides", and forwarding and routing covers the router side. But the sending host has already made a decision before any router sees the packet. RFC 1122 section 3.3.1 (host requirements, routing outbound datagrams) tells a host to decide whether the destination is on a directly connected network using the subnet mask, and otherwise to pick a gateway. The table that holds the answer is the same kind a router has, only smaller.
Take a laptop at 192.168.1.50/24 with its gateway at 192.168.1.1. DHCP is where the gateway normally comes from. Its Linux routing table, as ip route prints it (ip-route(8)), is (illustrative):
| Row | Destination | Via | Dev | Meaning |
|---|---|---|---|---|
| 1 | 192.168.1.0/24 | (none) | eth0 | Connected route. The network is on this link, so deliver directly: no gateway, ARP for the destination itself. |
| 2 | default (0.0.0.0/0) | 192.168.1.1 | eth0 | Default route. Anything not matched above goes to this next hop: ARP for the gateway, send the frame to its MAC. |
The /24 comes from the mask handed out with the address; the AND of address and mask is what makes row 1 match or not. Row 2 matches every address because its prefix length is 0, so it wins only when row 1 does not match: that is the same longest-prefix rule routers use.
The decision
The mask arithmetic and a worked /27 example are on IP addressing; this page starts where that one stops. The ARP exchange itself (broadcast request, unicast reply, cache) is on ARP. Here only its target matters: the destination's IP in the local case, the gateway's IP in the remote case.
Worked example: ping 8.8.8.8
The laptop 192.168.1.50 (MAC 02:00:00:00:00:50) runs ping 8.8.8.8 (ICMP and ping). The addresses and MACs here are illustrative; 8.8.8.8 is Google Public DNS.
- Route lookup.
8.8.8.8 AND 255.255.255.0is8.8.8.0, which is not192.168.1.0, so row 1 does not match. Row 2, the default route, does. Next hop:192.168.1.1. - ARP for the gateway, not for
8.8.8.8. The gateway's MAC comes back (02:00:00:00:00:01) and is cached. - Frame 1 leaves with MAC dst = gateway, MAC src = laptop. Inside, the IP header says src
192.168.1.50, dst8.8.8.8, TTL 64 (the usual default; see The IP Packet for the header). - The gateway reads the frame addressed to its MAC, strips the L2 header, finds no better route than its own default, decrements TTL, recomputes the checksum and builds a new frame for the next link. Because it is a home router doing NAT, it also rewrites the source IP from
192.168.1.50to its public address. - Each later router repeats step 4 minus the NAT: new MACs, TTL minus 1, new checksum, same IPs.
| Field | Changes per hop? | Why |
|---|---|---|
| MAC dst and MAC src | Yes, every hop | A MAC only names a device on the current link. Each router builds a new frame for the next link. |
| TTL | Yes, minus 1 per router | It is a hop budget that stops loops; RFC 1812 has routers decrement it. |
| IP header checksum | Yes, recomputed | It covers the header, and TTL changed. See the checksum worked by hand. |
| IP destination | No | It is the end-to-end address every router's lookup keys on. |
| IP source | No, unless a NAT is on the path | A NAT rewrites it (and the port) so replies come back to the NAT's public address. |
| Payload (the ICMP echo) | No | Routers do not look inside the payload. |
On the way back, the reply to 203.0.113.7 reaches the NAT, which looks up its mapping and rewrites the destination back to 192.168.1.50. That is the NAT page's story; the point here is the host's decision: every packet the laptop originates for an address off its subnet takes steps 1 to 3.
Try it: step a ping across three routers, set the TTL to 2 to see it die at R2, point it at an address on the host's own subnet to skip the routers, or break the gateway to leave ARP unanswered. The walker has no NAT, so the source IP stays constant all the way.
| Prefix/len | Next hop | Interface | Source | AD (Cisco default) | Metric | Against this destination |
|---|---|---|---|---|---|---|
| no match | ||||||
| matched: used |
RFC 1812: a router decrements TTL, recomputes the header checksum, and discards a packet whose TTL would reach 0, returning ICMP Time Exceeded (type 11, RFC 792). MACs only name a device on the current link; IP addresses name the endpoints. Addresses and MACs here are illustrative.
Deep dive
Multiple interfaces and metrics
A host with more than one interface (Wi-Fi plus Ethernet, or a VPN adapter) can have several routes that match. Longest prefix wins first. When prefixes are equal, the metric breaks the tie: the lower metric is preferred, as ip route shows it. A VPN client can take over traffic without deleting the existing 0.0.0.0/0 by installing two more specific routes, 0.0.0.0/1 and 128.0.0.0/1, which together cover everything and each beat the default on prefix length.
Policy routing
Linux can consult more than one table. ip rule (ip-rule(8)) chooses a routing table from the packet's source address, firewall mark, or incoming interface, and each table has its own default route. This is how a host with two uplinks can answer on the interface a request arrived on. The ordinary host decision on this page is the single main table.
On-link routes and the /32 case
A route with a gateway normally requires the gateway to be inside a connected subnet. ip route has an onlink flag (ip-route(8)) that tells the kernel to treat the next hop as directly reachable on the device even if no connected route covers it. It exists for setups where a host has a /32 address and a gateway that no subnet derived from its own address would contain. If you see a /32 address with a default via ... onlink route on a cloud instance or a container, that is what makes it work: the host ARPs for the gateway directly. Check ip route on the instance to see what your image installs.
Proxy ARP
If a host believes a remote address is on-link (for example, a mask that is too short) it ARPs for that address directly. No device on the link owns it, so no reply comes. Proxy ARP (RFC 1027) lets a router answer that ARP request on behalf of the remote host, so the packet arrives anyway, addressed to the router's MAC. It hides misconfiguration and grows ARP tables, which is why a host can "work" with the wrong mask on some networks and fail on others.
ICMP redirects
A host may have only a default route, so it sends a packet to the gateway even when a different router on the same link is the better next hop. The gateway forwards it and also sends an ICMP redirect (type 5, defined in RFC 792) naming the better router; RFC 1122 section 3.3.1 covers what a host does with it. Whether a host acts on redirects is a setting. On the macOS machine used for this page, sysctl net.inet.icmp.drop_redirect is 1 (redirects are dropped). On Linux, accept_redirects and related knobs are documented in the kernel's ip-sysctl reference; read the default for your kernel there rather than assuming it. Redirects can be abused to steer a host's traffic, which is why hardened hosts turn them off.
Gateway down
If the gateway is unreachable, ARP for it gets no reply and every packet on the default route fails, while on-link traffic (other hosts on the same subnet, which do not use the gateway) keeps working. RFC 1122 section 3.3.1 discusses dead-gateway detection for hosts with several gateways. On a single-gateway host the symptom is simply: the LAN works, the internet does not.
Textbook vs real world
| The textbook says | Production does | Why |
|---|---|---|
| Hosts send everything to the router and the router decides. | The host makes a local-versus-remote decision first, from its own routing table. | Local traffic must not go through the gateway: it would waste the gateway and fail if the gateway were down. |
| A host has one gateway and a two-row table. | Laptops and servers often have several interfaces, metrics, VPN routes and policy tables. | VPN clients and containers install routes of their own. |
| The gateway is a router inside your subnet. | Some images use a /32 host address and an on-link route to the gateway. | The onlink flag allows a next hop that no connected route covers. Check ip route on the instance. |
| ICMP redirects teach hosts better routes. | Many hosts ignore or drop them. | They can be used to steer traffic, so hardened systems disable them. |
In production
- Containers get a virtual Ethernet pair (veth) with one end in the container's network namespace. Inside, a container on the default Docker bridge typically has the same two-row table: a connected route for the bridge subnet and a default route via the bridge's address. See the Docker bridge network documentation.
- Kubernetes requires that pods reach other pods without NAT (Kubernetes network model); how that is met depends on the CNI plugin, and every pod's packets still start with the pod's own host routing decision.
- Cloud instances get their default gateway from the provider's DHCP. In an AWS VPC the subnet's base address plus one (for example
10.0.0.1in10.0.0.0/24) is reserved for the VPC router (subnet CIDR reservations), and where that router sends the packet next is set by the VPC's route tables, covered on VPCs, subnets and routing. The host's table decides how a packet reaches that router; the cloud route table decides where it goes after. - VPN split tunnelling is a host-routing feature: the client adds routes for the corporate prefixes through the tunnel interface and leaves the default route on the physical interface. See VPNs and IPsec.
History and evolution
- 1981 RFC 791 specifies IP, and RFC 792 defines the ICMP redirect so a gateway can tell a host about a better first hop. Hosts are configured by hand with static addresses and routes.
- 1989 RFC 1122 (host requirements) sets how a host picks local versus remote delivery and a gateway, once subnet masks exist.
- 1997 DHCP (RFC 2131) delivers the address, mask and default gateway automatically, so the two-row table is built without a human.
- Now Hosts commonly carry extra routes from VPNs, containers and cloud agents, and hosts are free to ignore redirects. Linux exposes policy routing and multiple tables.
- Next IPv6 hosts learn their default router from router advertisements instead of DHCP (IPv6); the decision itself is unchanged.
Hands-on
macOS (real output from one machine, abbreviated; addresses will differ). The route to a public address resolves to the default route:
destination: default is the default route and gateway is the next hop. Now the whole table:
The 192.168.0 row with gateway link#15 is the connected route: no IP next hop, the destination is on the link. The G flag on the default row marks a gateway route. The 192.168.0.1 row is the neighbour entry for the gateway (MAC elided here), the ARP result for the next hop. The ping itself, from the same machine:
The ttl=116 is the TTL the reply had when it arrived. You do not know the replier's initial TTL, so you cannot compute an exact hop count from it. The laptop's own initial TTL on this macOS machine is 64 (sysctl net.inet.ip.ttl).
On Linux (illustrative; adapt interface names):
ip route get shows the decision itself: via 192.168.1.1 means the remote branch, and for an address on your subnet it prints no via. ip neigh shows the gateway's MAC cached by ARP. tcpdump -e prints the link-layer header, so you can see that the destination MAC is the gateway's while the IP destination is 8.8.8.8. traceroute -n 8.8.8.8 (how it works) shows the later hops, and its first line is the gateway.
Gotchas
Interview questions
Show answer
The laptop ANDs 8.8.8.8 with its mask, sees it is not on its subnet, and falls through to the default route. It ARPs for the gateway's IP, builds an ICMP echo request with IP dst 8.8.8.8, and sends it in a frame whose destination MAC is the gateway's. The gateway strips the frame, decrements TTL, recomputes the checksum, NATs the source address if it is a home router, and forwards on a new frame. Each router repeats the L2 rewrite until the last one delivers the packet to 8.8.8.8, which replies by the reverse path.
Follow-ups:
- Does the laptop ARP for 8.8.8.8? No. ARP never crosses a router, so it ARPs for the next hop.
- Where does DNS fit? Not at all, since the target is an IP. A name would add a DNS lookup first.
- How does the reply find its way back? Routers forward by destination IP; the NAT maps the reply to the laptop.
Show answer
It ANDs the destination address with its own subnet mask and compares the result to its own network address. A match means local: deliver directly on the link. No match means remote: send to the default gateway.
Follow-ups:
- Where does the mask come from? Usually DHCP, or static configuration.
- What if the mask is wrong? Local and remote get confused; see the gotcha on masks.
Show answer
The default gateway's. The IP header carries the final destination, but the frame is only addressed to the next hop on the local link.
Follow-ups:
- How does the host learn it? ARP for the gateway's IP.
- Does it change later? Yes, at every router.
Show answer
The MAC addresses change on every link, TTL drops by 1 per router, and the IP header checksum is recomputed because TTL changed. The IP source and destination stay the same, unless a NAT rewrites the source.
Follow-ups:
- Why must the checksum change? It covers the header, and TTL is in the header.
- What stops loops? TTL: at 0 the router drops the packet and sends an ICMP time exceeded.
Show answer
Work outward. Check the address and mask, then the routing table for a default route, then ping the gateway, then ping a public IP such as 8.8.8.8, then resolve a name. A missing default route or wrong gateway points at DHCP or static config; IP works but names fail points at DNS.
Follow-ups:
- Ping to 8.8.8.8 works but names fail? DNS resolver configuration.
- Gateway ping fails? Check ARP for the gateway and the link itself.
Show answer
It is the router a host sends packets to when the destination is not on its own subnet. In the routing table it is the next hop of the default route, 0.0.0.0/0.
Follow-ups:
- Can a host have more than one? Yes; metrics pick between them.
- How does a host get it? Typically from DHCP.
Show answer
Proxy ARP is a router answering an ARP request for a host on another network with its own MAC, so a host with the wrong mask can still reach it. An ICMP redirect is a gateway telling a host "use that other router for this destination". Both paper over host misconfiguration or a suboptimal first hop, and both are commonly disabled for security and predictability.
Follow-ups:
- Why is a redirect risky? A device on the link can use it to steer a host's traffic.
- Where are they specified? Proxy ARP in RFC 1027, redirects in RFC 792.
Fun facts
- The default route is
0.0.0.0/0, the shortest possible prefix: it matches every address and loses to any other match. - A host with IP forwarding off (as on the macOS machine used here, where
net.inet.ip.forwardingis0) does not forward packets that were not addressed to it; it only originates and receives. ip route getasks the kernel to make the decision and prints the answer without sending anything.
Cheat sheet
| Situation | Next hop (ARP target) | Frame dst MAC | IP dst |
|---|---|---|---|
| Destination on my subnet | The destination | Destination's MAC | Destination |
| Destination off my subnet | Default gateway | Gateway's MAC | Destination (unchanged) |
| Specific route (VPN, container) | That route's gateway | That gateway's MAC | Destination (unchanged) |