DHCP Scope Sizing & Lease Times¶
A scope sized for the number of people in the room runs out, because addresses are held by leases, not by devices. A client that walks out of the building without releasing its lease keeps the address until the lease expires. On a network with high churn, the pool is therefore sized by lease time as much as by headcount.
This page builds on DHCP Fundamentals — the DORA exchange and relay behaviour are covered there.
Count Devices, Not People¶
Assume two to three connected devices per person — phone, laptop, watch, tablet — and that most of them associate automatically without anyone deciding to connect. A 700-person venue is a 1,500–2,000 device problem, not a 700 address one.
Separately, keep infrastructure out of the pool entirely. Switches, APs, firewall interfaces and printers belong in a static range outside the scope, or in reservations, so pool exhaustion can never take management access down with it.
The Sizing Formula¶
addresses in use ≈ peak concurrent devices + (departures per hour × lease time in hours)
The second term is the dead weight — addresses held by devices that have already left. It scales linearly with lease time, which is why the default 24-hour lease is the wrong setting for a transient population.
For 2,000 peak concurrent devices with 300 devices per hour arriving and leaving:
| Lease time | Addresses in use | Dead weight |
|---|---|---|
| 30 min | 2,150 | 150 |
| 1 hour | 2,300 | 300 |
| 2 hours | 2,600 | 600 |
| 8 hours | 4,400 | 2,400 |
| 24 hours | 9,200 | 7,200 |
At 24 hours the pool needs to be more than four times the size of the actual client population. At one hour it needs 15% headroom over peak.
Choosing a Lease Time¶
- 1–2 hours suits a public or guest network where people arrive and leave through the day
- 30 minutes for very high churn, or where the pool is already tight
- Do not go below about 15 minutes — renewal happens at T1, 50% of the lease, so a 10-minute lease has every client renewing every five minutes for no useful gain
- 12–24 hours is fine for a stable staff or crew network where the same devices return
Renewals are unicast to the server, so they do not carry the broadcast cost of the initial DORA. The reason not to set leases very short is server load and client-side churn, not airtime.
Turning Addresses Into Subnets¶
| Prefix | Usable addresses |
|---|---|
| /24 | 254 |
| /23 | 510 |
| /22 | 1,022 |
| /21 | 2,046 |
| /20 | 4,094 |
The obvious response to needing 2,300 addresses is a single /20. Do not do this. A flat subnet of that size puts every client in one broadcast domain, and broadcast traffic scales with the size of that domain — the problem described in High-Density WLAN Tuning.
Split the requirement across several VLANs instead. The same 2,300 addresses as four /22 scopes gives 4,088 total with generous headroom, and four broadcast domains a quarter the size. Size each scope for roughly twice its expected peak, since clients do not distribute evenly across VLANs.
Idle Timeout Is Not the Same Lever¶
Shortening the AP's client idle timeout deauthenticates quiet clients. That frees an association slot and stops the AP tracking a device that has gone, but the DHCP lease is unaffected — it is held by the server until it expires regardless of whether the client is still associated.
The two settings solve different halves of the same problem and both need setting:
| Setting | Frees | Lives on |
|---|---|---|
| Client idle timeout | Association slot, AP client table entry | AP / controller |
| Lease time | IP address in the pool | DHCP server |
Recognising Exhaustion¶
Pool exhaustion does not look like a DHCP fault. The client associates to the WLAN normally, shows full signal, and then has no address and no internet — so it gets reported as "the WiFi is broken".
- Check pool usage on the DHCP server before assuming a wireless problem
- A client sitting on a 169.254.x.x APIPA address is the giveaway
- Watch pool usage as a live metric during peak, not afterwards — by the time users complain, the pool has been full for a while