Troubleshooting: An Address Is Not Enough

When the lease succeeds and the network still does not work

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Recognise a successful lease that is nonetheless incomplete
▸Predict exactly which traffic works when the gateway option is missing
▸Explain why this looks like an outage while local traffic is fine

Before this lesson — it builds directly on:

DHCP does not just hand out an address. It hands out a *set* of settings — the address, the mask, the gateway, the resolvers, how long the lease lasts. And here is the catch: if one of them is missing, that is not an error. The client asked for it; the server did not send it; nothing anywhere reports a problem. The client takes what it is given and configures itself with a hole in it. So you get a machine that completed DHCP perfectly and still cannot reach anything.

✗ Common misunderstanding: If DHCP completed successfully, the machine is correctly configured.

Why that's wrong: DHCP hands out a set of options. A missing one is not an error — the client takes what it is given and has no way to know something is absent.

Correct model: A successful lease says the exchange worked, not that the configuration is complete. Read the options actually delivered.

The packets prove it: In the no-gateway trace the ACK arrives with an address, a mask and a resolver, and no router option. Nothing reports a problem, and every remote destination fails.

Watch these fields in the lab: dhcp.option[0]

The machine has 10.0.1.55/24 and no default route. Trace two destinations.

  To 10.0.1.20  (a neighbour):
     10.0.1.20 AND 10.0.1.55 mask to 10.0.1  →  same subnet
     the connected route covers it            →  resolve its MAC, send
     WORKS

  To 203.0.113.80  (a server elsewhere):
     203.0.113 ≠ 10.0.1                       →  remote
     look for a route …
        10.0.1.0/24   does not contain it
        (no default route exists)
     no match at all                          →  nothing to send it to
     FAILS — and not one packet is transmitted

  Every local diagnostic passes. Link up, address valid,
  ARP working, neighbour answering. And nothing works.

The asymmetry is what makes this hard. A checklist that confirms the machine is 'on the network' passes completely, because it is on the network — it just has nowhere to send anything that is not on this wire. And because the route lookup fails before any packet is built, the capture shows an absence rather than a failure.

Watch these fields in the lab: ipv4.destIp

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why did nothing report that a requested option was missing?

A user says 'the internet is down' but can print to the printer next to them. What does that combination suggest?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.