Half the building’s Wi-Fi ‘broke’ at 9am and it turned out to be a subnet sized two years ago

The ticket queue floods at 9:15 Monday morning: half the building can't get online. Full signal bars, laptop joins the SSID without a fight, then nothing loads. First instinct is to blame the access points, maybe interference, maybe firmware. Then someone runs ipconfig on an affected machine and sees 169.254.something. That's an APIPA address, the one Windows self-assigns when it never hears back 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 stop thinking about right after their networking class covers it: Discover, Offer, Request, Acknowledge, DORA for short. A device joins and broadcasts asking for an address, a DHCP server offers one from its configured pool (the scope), the device asks to take it, the server confirms. Every step depends on the scope having something left to offer. When it doesn't, the device times out and falls back to assigning itself a 169.254.0.0/16 address, one that talks to other devices on the same broken segment and nothing else. No dialog box says "the DHCP scope is full." It just quietly stops working, and from the user's side it looks exactly like a Wi-Fi outage.

Scopes run dry for two reasons that compound each other. Sometimes the pool's just too small for how many devices are actually on the network now, sized for 200 addresses on a segment that's grown to 300 phones, laptops and random IoT devices since anyone last checked. And lease time makes it worse: a long lease (default is often eight days) means a device that connected once and left keeps its address reserved for over a week after it's physically gone. On a network with a lot of transient devices, guests, BYOD, long leases mean the pool fills with addresses nobody's using, and there's nothing left for a new device walking in the door.

Diagnosing it takes about two minutes once you know to look. Check the DHCP server's scope statistics for percent utilization, not just whether the service is running. A scope sitting at 98-100% explains the whole ticket queue on one screen. From there, one of two fixes: shorten the lease time so stale reservations clear faster (usually right for a guest/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 that segment needs today. That second option is where a subnet sized two years ago for a smaller building quietly becomes today's outage. The subnetting decision and the DHCP failure aren't two separate problems, the second is just the first one showing up late.

Codelivly's Network Engineer L1 Book is built around exactly this kind of scenario: subnetting, VLANs, routing, DNS and DHCP, taught through 12 hands-on labs and 30 real scenarios, plus 100+ interview questions that test whether you can actually reason through a ticket like this instead of just reciting DORA. If subnetting's stayed mostly theoretical, the free Routing & Switching Fundamentals and Network Services Administration paths on codelivly.com are where that theory turns into reading a scope utilization number and immediately knowing what it means.