DHCP
DHCP hands a host its IP address, subnet mask, default gateway, DNS servers, and a pile of other config the moment it boots with nothing. A device that has never been on the network sends one broadcast, and within a couple of round trips it has everything it needs to route. The four-step DORA exchange — Discover, Offer, Request, Acknowledge — leases that address for a bounded time rather than granting it forever.
DHCP is invisible until it breaks, and then it breaks loudly: a dead or full DHCP server means every device that reboots or renews can no longer get an address, and half the network falls off at once. The symptom is unmistakable once you know it — hosts showing a 169.254.x.x link-local address, which is what a machine assigns itself when no DHCP server answers.
The DORA Exchange
The four steps run mostly over broadcast, because the client has no address yet and does not know where the server is. Discover: the client broadcasts "is there a DHCP server?" Offer: one or more servers reply with a proposed address. Request: the client broadcasts its acceptance of one specific offer — broadcast, so the servers it declined know to release their reservations. Acknowledge: the chosen server confirms, and the lease is now active.
The request is broadcast on purpose. If two servers both made offers, the broadcast Request names the one the client picked, so the other server sees it was not chosen and returns its tentatively-reserved address to the pool. Skip that detail and you misread why a second DHCP server's addresses appear to leak.
# DORA seen from the client side (journalctl on the dhcp client) journalctl -u systemd-networkd -f # DHCPv4: DISCOVER (broadcast: any server out there?) # DHCPv4: OFFER 10.0.5.84 from 10.0.5.1 (server proposes an address) # DHCPv4: REQUEST 10.0.5.84 (broadcast: I'll take this one) # DHCPv4: ACK lease 10.0.5.84/24 gw 10.0.5.1 dns 10.0.5.2 t=86400
Leases and Renewal
An address is a lease, not a gift — it comes with a lifetime, often 8 or 24 hours on a busy network, longer where addresses are plentiful. The client does not wait for expiry to renew. At T1, half the lease time, it unicasts a renewal directly to the server that granted the lease. If that fails, at T2 — 87.5% of the lease — it broadcasts, asking any server to extend it. Only if both fail and the lease fully expires does the client give up the address and start over with Discover.
Expiry is the part that bites. If the client cannot renew before the lease runs out — server down, network partition — it must stop using the address, because the server is free to hand it to someone else. A short lease time means faster reclamation of addresses from departed devices but more renewal traffic; a long lease means the opposite, and a pool that fills with stale leases from devices that left without releasing.
DHCP Options
The address is only the headline. DHCP carries a long list of numbered options alongside it: option 3 is the default gateway, option 6 the DNS servers, option 15 the domain name, option 42 NTP servers, option 51 the lease time. The same exchange that addresses a host also tells it how to reach the rest of the network — which is why a wrong DNS option, not a wrong address, is a common DHCP misconfiguration.
Options also drive network boot. Option 66 and 67 point a diskless or PXE-booting machine at a TFTP server and a boot file, so a bare machine can pull its operating system over the network. The breadth is the point: DHCP is less an address dispenser than a config-on-boot mechanism, and most of what it delivers is not the IP at all.
Relays and Scope
DHCP Discover is a broadcast, and routers do not forward broadcasts — so a single central DHCP server cannot, on its own, serve a host on a different subnet. A DHCP relay (IP helper) bridges that gap: configured on the router for each remote subnet, it catches the local broadcast, unicasts it to the central server with the subnet's identity attached, and relays the reply back. This is how one DHCP server serves dozens of subnets without a server on each.
A scope is the pool of addresses a server can hand out for a given subnet, and pools are finite. When a scope exhausts — more devices than addresses, or stale leases hogging the pool — new clients get nothing and end up on 169.254.x.x. Guest networks with high device turnover and short leases are where exhaustion shows up first, and the fix is a larger pool or shorter leases, not a faster server.
DHCP leases addresses dynamically from a central server and delivers gateway, DNS, and dozens of options with them. It is the right default for clients — laptops, phones, desktops — where you want central control and no per-device touch. Static addressing fixes an address by hand on the host, with no lease and no dependency on a server being up; use it for routers, DNS servers, and anything that must keep one address even if DHCP is down.
SLAAC is the IPv6 way: the host self-assigns from a router-advertised prefix with no server tracking leases at all. The practical split is servers static, clients DHCP, and IPv6 segments SLAAC — and on dual-stack networks a server gives addresses by DHCP for v4 and SLAAC announces the v6 prefix at the same time.
- Running two DHCP servers on one segment with overlapping scopes. They hand out conflicting or duplicate addresses, and clients get intermittent address conflicts that are maddening to trace because the offer they accept varies by timing.
- Letting a scope exhaust on a high-churn network. Once the pool is empty, new clients get no lease and self-assign 169.254.x.x — the network looks broken for newcomers while existing leased hosts work fine, masking the cause.
- Assigning a static IP that falls inside the DHCP pool. The server eventually leases that same address to another host, producing a duplicate-address conflict that takes one or both hosts off the network until someone notices.
- Relying on DHCP-supplied DNS for critical servers. If the DHCP server's option 6 changes or it hands out a dead resolver, those servers lose name resolution on the next renewal — give infrastructure static DNS instead.
- Forgetting the relay on a remote subnet. With no IP helper, the central server never hears the broadcast Discover, so a whole subnet quietly gets no addresses while the server itself looks healthy.
- Reserve addresses by MAC for servers and printers, or give them statics outside the pool entirely, so infrastructure keeps a fixed address and never collides with a dynamic lease.
- Carve the static range out of the subnet and point the DHCP scope only at the remainder, so a hand-assigned address can never be inside the pool the server draws from.
- Configure a DHCP relay (IP helper) on the router for every subnet that lacks a local server, so one central server can lease addresses across all of them instead of needing a server per segment.
- Run exactly one authoritative DHCP server per scope, or a coordinated failover pair that splits the pool, rather than two independent servers that fight and issue conflicting addresses.
- Tune lease time to device turnover — short on guest and high-churn networks to reclaim addresses fast, long on stable office segments to cut renewal traffic — and size the pool with headroom above peak device count.
Knowledge Check
In the DORA exchange, why is the client's Request message broadcast rather than unicast to the chosen server?
- So servers whose offers were declined learn they were not chosen and release the addresses they reserved
- Because the client still has no way at all to learn the chosen server's address until the Acknowledge finally arrives
- Because a broadcast Request is cryptographically signed and a unicast one is not
- Because DHCP relays can only forward broadcast traffic, never unicast packets
A host on a working network shows a 169.254.x.x address. What is the most likely cause?
- DHCP did not answer — the server is down or its scope is exhausted, so the host self-assigned link-local
- The DHCP server intentionally leased a link-local address from its 169.254 pool
- The host renewed its existing lease successfully and simply kept the previous routable address it already held
- SLAAC assigned it an IPv4 address automatically without contacting any server
Why do infrastructure servers usually get static or reserved addresses instead of plain DHCP leases?
- A fixed address survives a DHCP outage and never changes, keeping the server reachable when the lease server is down
- DHCP servers are simply unable to assign any address at all to a machine that itself happens to run network services for other clients
- A static address routes packets measurably faster than a leased dynamic one
- A leased address is unencrypted on the wire while a static one is protected
You got correct