TL;DR: An initial DHCP exchange commonly follows Discover, Offer, Request, Acknowledge. Client discovery and selecting requests broadcast; server replies can broadcast or unicast depending on client state, flags and relay handling. In practice it fails at a missing relay agent, an exhausted pool, or a firewall eating UDP 67 and 68, rarely at the protocol itself.
How to approach it
Name the four packets in order and what each settles, then trace the path from the client's segment toward the server. The interviewer wants to know whether you have watched the exchange or only memorised the acronym. Mentioning the relay agent early is usually what separates the two.
A strong answer
The exchange runs Discover, Offer, Request, Acknowledge. The client boots with no address and transmits DISCOVER from 0.0.0.0:68 to 255.255.255.255:67. Every server on the segment answers with an OFFER proposing an address, subnet mask, router and DNS options, and a lease duration. The client broadcasts a REQUEST that echoes the server identifier of the offer it accepted, so losing servers return their proposals to the pool. The winner confirms with an ACK. The client binds the address and starts two timers: renew by unicast at T1 and rebind by broadcast at T2 if renewal fails. Defaults are 50% and 87.5% of the lease, but the server can supply other values.
| Packet | Direction | What it settles |
|---|---|---|
| DISCOVER | client, broadcast | I need an address, send offers |
| OFFER | server | proposed IP, mask, router, lease time |
| REQUEST | client, broadcast | which server's offer I accept |
| ACK | server | final parameters, renewal timers start |
Anything larger than one flat subnet has a relay agent in the path. The router facing the client converts the broadcast into a unicast packet addressed to the central DHCP server and stamps its own interface address into the giaddr field. The server selects the pool matching giaddr. This one field explains most real incidents: a new VLAN provisioned without a relay, or a relay pointing at the wrong pool.
Failure points, roughly in the order I would check them. Did DISCOVER leave the host: tcpdump -ni eth0 'port 67 or port 68' shows which quarter of the exchange goes missing. Then relay configuration on the client's VLAN. Then pool exhaustion, visible in the server's lease view. Then an ACL filtering UDP 67 or 68 along the relayed path. Last, a rogue server answering faster with a bad router option, which produces connectivity that works for some destinations and not others.
Two DHCP servers on one subnet are legal and common for redundancy. Use coordinated failover/shared state or nonoverlapping address pools so they cannot allocate the same address to different clients. Inconsistent options can also break connectivity, say different router options, and clients land on good or bad settings depending on which server replied first.
An address in 169.254.0.0/16 means the client gave up: DISCOVER went unanswered long enough that it self-assigned a link-local address. Link-local addressing can indicate failed DHCP, but does not identify which exchange phase failed and can also be configured deliberately.
What interviewers probe next
"Why is the REQUEST broadcast rather than sent straight to the winning server?" The other servers hear it and learn they were not chosen, so they free their reservations.
"What happens when the lease expires during a DHCP server outage?" Renewal fails at T1, rebind fails at T2, and on expiry the client drops the address rather than squatting on it. Lease length is a resilience decision, which is why hours-long leases exist.
"How would you find a rogue DHCP server?" Disconnect a test client, trigger a DISCOVER, and read the server identifier on the OFFER, or run nmap's broadcast-dhcp-discover script.
Common mistakes
Reciting DORA letters without the packet fields. Letters score nothing; the giaddr story scores.
Blaming the DHCP server first when the new VLAN never had a relay configured.
Treating an APIPA address as a random glitch instead of a reason to inspect the full DHCP exchange and client configuration.
References