The ticket queue floods at 9:15 on a Monday: half the building can't get on Wi-Fi. Signal bars are full, the laptop connects to the SSID without a fight, and then nothing loads. The instinct is to blame the access points, maybe a firmware issue, maybe interference from the new microwave in the break room. Then someone runs ipconfig on an affected machine and sees 169.254.x.x. That's an APIPA address, the one Windows assigns itself when it never got a response from a DHCP server. The Wi-Fi was never the problem. The building ran out of IP addresses to hand out.
DHCP is a four-step handshake most people never think about after their networking class: Discover, Offer, Request, Acknowledge, DORA for short. A device joins the network and broadcasts "does anyone have an address for me," a DHCP server offers one from its configured pool (the scope), the device asks to actually take that address, and the server acknowledges it. Every step of that depends on the scope having an address left to offer. When it doesn't, the device waits out a timeout and falls back to self-assigning an address in the 169.254.0.0/16 range, one that can talk to other devices on the same broken segment but nothing beyond it. No error dialog says "the DHCP scope is full." It just quietly stops working, and it looks exactly like a Wi-Fi problem from the user's side of the ticket.
Scopes run dry for two reasons that compound each other. The pool itself might just be too small for how many devices are actually on the network now, a scope sized for 200 addresses on a subnet that has grown to support 300 phones, laptops and IoT devices since the last time anyone looked at it. And lease time makes it worse: a long lease duration (the classic default is eight days) means a device that connected once and left keeps its address reserved against the pool for over a week even though it's nowhere near the building anymore. On a network with a lot of transient devices, guest laptops, personal phones cycling in and out, BYOD, long leases mean the pool fills up with addresses nobody is actually using, and there's nothing left to hand a device that just walked in the door.
Diagnosing it takes about two minutes once you know to look. Check the DHCP server's scope statistics for percentage utilization, not just whether the service is running. A scope sitting at 98% or 100% utilized explains the whole ticket queue in one screen. From there the fix is one of two moves: shrink the lease time so stale reservations clear out faster, which is usually the right call for a guest or BYOD-heavy network, or actually resize the scope, which means going back to the subnet math and confirming the block size still fits how many hosts the segment actually needs to support. That second option is where a design decision made two years ago, back when the subnet was sized for a smaller building, quietly turns into an outage today. The subnetting choice and the DHCP outage aren't two separate problems. The second one is just the first one showing up late.
This is exactly the kind of scenario Codelivly's Network Engineer L1 Book is built around: subnetting, VLANs, routing, DNS and DHCP, taught through 12 hands-on labs and 30 real scenarios like this one, plus over 100 interview questions that test whether you can actually reason through a ticket like "half the building can't get online" instead of just reciting DORA. If subnetting has stayed theoretical so far, the free Routing & Switching Fundamentals and Network Services Administration learning paths on codelivly.com are where that theory turns into being able to read a scope utilization number and know exactly what it means.
Top comments (0)