On a Linux host, what does the `default` entry in the output of `ip route show` mean, and what happens to a packet whose destination matches no route in the table at all?
answer
- the catch-all for everything unmatched
- prefix length zero, matches everything
- tried last, not first
- gateway must be directly reachable
- immediate ENETUNREACH, not a timeout
basics
~20 sThe default route is the 0.0.0.0/0 catch-all entry telling the kernel where to send packets that no more specific route matches, normally via a gateway. With no match at all the send fails locally and immediately with ENETUNREACH, "Network is unreachable".
solid answer
~50 s`default` is how iproute2 prints the prefix 0.0.0.0/0 — a prefix length of zero, so it matches every destination and is therefore the least specific entry in the table. A line like `default via 192.168.1.1 dev eth0` says: for anything I have no better route for, hand the frame to 192.168.1.1 out of eth0. It is the last resort, not the first choice; more specific prefixes always win. The gateway itself must be reachable on a directly connected network — those `scope link` routes are installed automatically by the kernel when you assign an address, which is why a host with no default route can still talk to its own LAN. If no route matches, the failure happens before anything leaves the box: `connect()` or `sendto()` returns ENETUNREACH and tools print "Network is unreachable" instantly, with no timeout and no packet on the wire.
go deeper
Be able to read a route line out loud: prefix, via gateway, dev interface. Say plainly that default means 0.0.0.0/0 and is used only when nothing more specific matches.
Explain that lookup is longest-prefix match, that scope link routes come from assigned addresses, and why a gateway must live inside a connected prefix. Know that ENETUNREACH is raised by the syscall before transmission.
Use the error's timing as a diagnostic signal: instant ENETUNREACH is a local table problem, a hang is not. Check IPv4 and IPv6 tables separately, and know that ip route add is not persistent across reboots.
Own the policy: how default routes are sourced across a fleet (DHCP, RA, static, or a routing daemon), what happens to hosts that hold two of them, and how you keep host routing simple enough that on-call engineers can reason about it.
## What the routing table is The Linux kernel keeps a Forwarding Information Base (FIB) — the structure `ip route show` renders in human form. Every entry answers one question: *for a destination in this address range, what is the next hop and which interface do I send it out of?* A typical entry has these parts: ``` default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.50 metric 100 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50 ``` - **the prefix** (`default`, `192.168.1.0/24`) — the range of destinations this entry covers. - **`via <addr>`** — the next-hop gateway. Absent means the destination is on-link. - **`dev <iface>`** — the egress interface. - **`proto`** — who installed it: `kernel` (derived automatically from an assigned address), `dhcp`, `static`, `ra`. - **`scope link`** — this network is directly reachable; no gateway is involved. - **`src`** — the preferred source address to stamp on packets using this route. - **`metric`** — a preference number used to break ties between routes to the *same* prefix. ## Why "default" is special only in how it prints `default` is not a magic keyword in the kernel; it is the prefix `0.0.0.0/0`, i.e. zero significant bits. Because lookup is longest-prefix match, a prefix of length zero is the weakest possible match and therefore only ever used when nothing else matched. Interviewers like this because candidates often describe the default route as "where traffic goes first". It is the opposite: it is where traffic goes last. ## The two kinds of destination When you assign an address with a prefix — say 192.168.1.50/24 — the kernel installs a `scope link` route for 192.168.1.0/24 out of that interface, with `proto kernel`. Destinations inside that range are **on-link**: the kernel resolves the destination's own MAC address via ARP (or Neighbour Discovery for IPv6) and sends the frame directly. Everything else is **off-link** and needs a router. The default route names that router. Note the consequence: a gateway address must itself fall inside a directly connected prefix, otherwise the kernel has no way to reach it. Trying to install one that does not is rejected up front: ``` # ip route add default via 10.9.9.1 RTNETLINK answers: Network is unreachable ``` This also explains why a host with no default route is not "offline" — it can still reach every machine on its own subnet perfectly well. It simply cannot leave it. ## What happens when nothing matches If the lookup finds no matching entry, the kernel does not queue, buffer or retry. The syscall that tried to send fails synchronously with errno **ENETUNREACH**, surfacing as "Network is unreachable": ``` $ ping 8.8.8.8 connect: Network is unreachable ``` The distinguishing feature is that it is *instant*. That single observation is diagnostically valuable: an immediate ENETUNREACH is a local routing-table problem on this host, whereas a hang followed by a timeout means the packet did leave and nothing came back, and EHOSTUNREACH usually means an on-link neighbour never answered ARP or a router returned ICMP host-unreachable. IPv6 behaves the same way with its own table; `ip -6 route show` is a separate view and a host can easily have a working IPv4 default route and no IPv6 one, which produces confusing "works for some names, not others" symptoms once a name resolves to an AAAA record. ## Confirming the decision instead of guessing Reading the table by eye scales badly. `ip route get` asks the kernel to perform a real lookup and report the answer it would use: ``` $ ip route get 93.184.216.34 93.184.216.34 via 192.168.1.1 dev eth0 src 192.168.1.50 uid 1000 ``` That output names the chosen next hop, the egress interface and the source address the packet would carry. It is the authoritative answer for a single destination, and it is what you should reach for before arguing about which line in the table "should" win. ## Practical notes Routes added with `ip route add` live only in kernel memory and vanish on reboot or on an interface restart; persistence is the job of whatever configures your interfaces. And a host can legitimately hold more than one default route — that is a preference question decided by metrics, not by table order.
- Why can a machine with no default route still ping its neighbours on the same LAN?Assigning an address such as 192.168.1.50/24 makes the kernel install a `scope link` route for 192.168.1.0/24 with `proto kernel`. Destinations inside that prefix match it, are treated as on-link, and are reached by ARPing for the host directly — no gateway and no default route is involved. Only off-link destinations need one.
- How would you tell an ENETUNREACH failure apart from a packet that left the host and was dropped upstream?Timing and error. ENETUNREACH is returned by the syscall instantly, before any packet is transmitted, and means this host had no matching route. A packet that left and died upstream shows up as a hang ending in a timeout, or as an ICMP-derived error such as EHOSTUNREACH. `ip route get <dst>` settles it: if it errors, the problem is local.
- Why does `ip route add default via 10.9.9.1` fail with "Network is unreachable" on a host addressed 192.168.1.50/24?Because the nexthop itself must be reachable without recursion. 10.9.9.1 is not inside any directly connected prefix, so the kernel cannot resolve a link-layer address for it and rejects the route at install time rather than accepting an entry it could never use.
saying these in an interview costs you the question
- Saying the default route is checked before more specific routes
- Claiming a host without a default route has no networking at all
- Expecting a timeout rather than an instant error when no route matches
- Setting a gateway address that is not on a directly connected subnet
- Confusing routing failure with a DNS or firewall problem