Watch DORA happen, then break it
Task
Run a DHCP server in your lab, capture the four-message exchange, then exhaust the pool and observe what a client does when there is nothing left. DORA is a four-letter acronym until you have watched the four packets.
Steps
- On Host B, configure a deliberately tiny scope so you can exhaust it. With dnsmasq that is one line in
/etc/dnsmasq.conf:dhcp-range=192.168.20.100,192.168.20.102,12h. Three addresses. Restart the service. - On Host A — temporarily moved to network 2, or using a second NIC — start a capture before requesting anything:
sudo tcpdump -i eth0 -n port 67 or port 68 -v. - Request a lease:
sudo dhclient -v eth0. Read the capture and identify all four messages — Discover from the client as a broadcast, Offer from the server, Request from the client, Acknowledge from the server. - Note the ports: the client sends from 68 to 67, and the server replies from 67 to 68. That pair is examinable and the capture shows it plainly.
- Now exhaust the pool. Request leases from three clients (or use
dhclientwith different MAC addresses via a namespace), then try a fourth. Observe that it gets no reply and self-assigns a 169.254 address.
Verify
sudo tcpdump -i eth0 -n -c 8 "port 67 or port 68"
ip -br addr show eth0
cat /var/lib/dhcp/dhclient.leases 2>/dev/null | tail -12 || cat /var/lib/misc/dnsmasq.leases
The capture must show the four DORA messages with the 67/68 port pair. The lease file must show the address, the server that granted it, and the expiry. And the fourth client must end up with a 169.254 address — which is the symptom, observed, of pool exhaustion.
Notes
The APIPA result is the whole point of the exercise. A host with a 169.254 address did not get a DHCP reply, and there are only a few reasons why: the server is down, the pool is exhausted, the relay is missing on a routed segment, or the port is in the wrong VLAN. Lesson 41 works through distinguishing them, and having caused one yourself makes that much faster.
Two more things to test while the lab is up. Add a reservation so one MAC always gets the same address, and confirm it survives a release and renew. Then add an exclusion and watch the server skip it — that is the mechanism which prevents the duplicate-address fault when a statically addressed printer lives inside the scope range.