DHCP Scope Exhaustion: Catch Full Pools Before Devices Fail

The first tickets usually say the Wi-Fi is broken on one floor. You check the access point, the switch port, and the upstream firewall, and every link is green, yet users sit there with addresses like 169.254.118.44 that nobody assigned. That address range is the signature of DHCP scope exhaustion: the server had no lease left to give, the device gave up and picked its own link local address, and by the time anyone looked, the pool had been empty for hours. Nothing about the failure points at DHCP, because devices that already held a lease kept working, so only new arrivals and renewals fell over while the rest of the segment carried on as if nothing happened.

Scope exhaustion is one of the most preventable failures in network operations, and also one of the most commonly missed, because almost nobody graphs pool utilization the way they graph CPU or disk. This guide walks through what actually happens when a scope fills, why pools fill without anyone noticing, the metrics and alert thresholds that catch it early, and the escalation path from lease cleanup to renumbering when a pool is genuinely out of room.

What Happens When a Scope Runs Out

DHCP follows a four step exchange usually written as DORA: discover, offer, request, acknowledge. When the scope has no free lease, the exchange breaks at the second step. The server either stays silent or answers with a negative acknowledgment, the client retries a few times, and then most operating systems fall back to Automatic Private IP Addressing and help themselves to an address in 169.254.0.0/16. From the device’s perspective it has an address, which makes the failure more confusing, because the user sees a connection with no internet rather than a clean error.

The sneaky part is who breaks and who does not. A laptop holding a lease with six days left keeps working through the whole incident. The new phone that joined this morning, the conference room device that rebooted, and any lease that expired mid morning are the ones that fail. That partial failure pattern is why exhausted scopes get misdiagnosed as wireless controller issues, authentication problems, or a bad switch, and why the fix often arrives long after the pool actually emptied.

Why Pools Fill Without Anyone Noticing

Most scopes are sized once, when the subnet is created, and then grow only by accident. The pool that comfortably held a hundred desktops in 2022 now also carries phones, tablets, visitor laptops, cameras, HVAC controllers, and whatever else got plugged in, and each of those holds a lease whether or not anyone remembers the device exists. Lease retention compounds the problem: a phone that connected once for a two hour meeting can hold its address for the full lease duration, and abandoned leases from departed devices sit in the pool until they expire naturally.

Growth also tends to arrive in bursts rather than as a steady slope. A new office floor, a migration of printers onto the same segment, or a Monday morning after a long weekend can move utilization ten points in a day. If you only ever look at the DHCP console when something breaks, the pool can sit at 96 percent for months and then cross the line on an ordinary Tuesday. The other silent contributor is self inflicted: static reservations carved out of the same pool, exclusion ranges nobody remembers the purpose of, and a duplicate DHCP server with an overlapping scope all shrink the effective pool without changing the number written in the design document.

The Metrics That Actually Matter

Utilization percentage is the headline number, but it has to be computed against the right denominator. The pool is the address range the scope is allowed to hand out, which is almost always smaller than the subnet it lives in. A /24 with a pool from .100 to .200 has 101 addresses to give, so 85 active leases is 84 percent utilization even though the subnet as a whole looks two thirds empty. Measuring against the subnet size hides exhaustion behind gateway, broadcast, and reserved space, and it is the most common reason teams believe they have headroom they do not have.

Beyond the headline number, four secondary signals tell you where the utilization is coming from. Active lease count and its week over week trend show whether growth is steady or bursty. The count of leases expiring within the next lease period predicts how quickly abandoned space will return. Decline and negative acknowledgment counters reveal clients rejecting offers or the server refusing requests, both of which spike around pool trouble. And the ratio of unique devices to active leases exposes churn: a guest network where 3,000 distinct MAC addresses cycle through a 200 address pool every week is running hot on utilization even though the instantaneous number looks calm, because a single burst day can drain it.

Thresholds Worth Alerting On

There is no industry standard threshold, because the right line depends on how fast your device count grows and how long it takes you to obtain more space. That said, the zones above work well as defaults. Below 50 percent, a pool is a non issue and only the trend deserves a glance. Between 50 and 75 percent you should already know what the response will be when you cross the next line, because the response, whether a lease cleanup, a scope expansion, or a renumbering, can take weeks of lead time in organizations with change control.

The crossing matters more than the level. A pool that moved from 60 to 74 percent in one month is a far more urgent conversation than one that has sat at 72 percent for a year. Whatever thresholds you pick, alert on the rate of change too, and remember that utilization at 9 a.m. on a quiet Friday tells you very little about the same pool at 9 a.m. on the Monday after a holiday weekend, when every laptop and phone in the building rejoins at once.

How to Monitor Scope Utilization in Practice

Start with whatever your DHCP server already exposes, because it is free and accurate. Windows Server publishes per scope utilization counters and can report on scopes above a configured percentage. Kea and ISC dhcpd expose lease statistics through their control channels and APIs, and dnsmasq administrators can read lease state directly from its lease file. If you run one or two servers, a scheduled script that polls these counters and pushes the numbers into your monitoring system is an afternoon of work that permanently removes the surprise factor.

The harder problem is not collecting the numbers, it is knowing what they mean. A utilization alert for a scope is only actionable if you can answer, without a hunt, which subnet the scope belongs to, where its pool boundaries are, how many static reservations sit inside them, and which team owns the segment. That context lives in your IP address plan, not in the DHCP server, which is why teams that document scope ranges against their subnets, the way IP address management in Obelinf lets you record pool boundaries alongside utilization, resolve exhaustion alerts in minutes instead of spending the first hour reconstructing the scope’s design from router configurations and old tickets.

Per server dashboards also hide the fleet view. If you operate DHCP at a dozen sites, the question “which scopes are above 75 percent anywhere” is one no individual server answers, and it is exactly the question worth scheduling as a weekly report long before any pool gets critical.

Fixing a Pool That Is Nearly Full

Work the list from least to most disruptive. First purge leases that no longer correspond to live devices, most DHCP servers let you query lease age and last activity, and a guest network six months into production usually has dozens of addresses held by hardware that left long ago. Second, audit static reservations: reservations belong outside the dynamic pool wherever possible, and half of them describe devices that were decommissioned without anyone touching the DHCP config. Third, shrink exclusion ranges and exclusions you no longer remember creating, after verifying nothing lives in them. Fourth, shorten the lease time on high churn scopes so abandoned addresses return in hours rather than days; this does not add capacity, but it makes every other measure recover faster.

When those measures are exhausted, you are adding space, and the options are a secondary subnet on the same segment, a split scope across two servers for resilience, or a renumber to a larger prefix. Renumbering is the clean fix and the expensive one, since it touches gateways, ACLs, DNS records, and every hardcoded address on the segment. Sizing the replacement scope is a subnetting exercise, and the subnet calculator in our toolkit makes it straightforward to compare prefix options and see how many usable addresses each candidate leaves after gateways and reservations.

Building the Habit Before the Next Empty Pool

The durable version of this discipline is small and boring. Every scope in your environment gets recorded once: its pool boundaries, its lease time, its reservations, and the subnet it belongs to. Utilization gets polled on a schedule rather than inspected during outages, thresholds get alerts attached, and each crossing of a threshold triggers a decision with a date on it rather than a note to keep an eye on things. Teams that operate this way treat pool space the same way they treat disk space, as a capacity metric with a growth curve, and scope exhaustion stops being an incident category entirely.

If you keep your address plan in Obelinf, recording each DHCP pool against its subnet means the boundaries, the utilization context, and the ownership are already in the same place an alert points you to, so the conversation starts with a decision instead of an investigation.