skip to content

A guest Wi-Fi DHCPv4 pool of 500 addresses runs dry by late morning with 24-hour leases; why, and how does a shorter lease fix it?

level: middleimportance: must knowfreq 34%

answer

  1. leavers rarely release
  2. a lease outlives the visit
  3. arrival rate times holding time
  4. silence, not a refusal
  5. short leases mean more renewals

basics

~20 s

Guests leave without releasing their leases, so each address stays allocated for the visit plus the rest of the lease. With 24-hour leases nothing frees up during the day; a one-hour lease bounds each address to the visit plus an hour.

solid answer

~50 s

RFC 2131 notes that a client does not normally send `DHCPRELEASE` even on a graceful shutdown, and a phone walking out of range sends nothing. So an address stays allocated until its lease expires: for the visit plus whatever is left of the lease. At 150 new guests an hour, a 500-address pool with 24-hour leases fills in about 3 hours 20 minutes, because nothing expires the same day. With a one-hour lease, a guest who stays an hour holds its address at most two hours, so at most 300 addresses are in use. When the pool is empty the server simply sends no `DHCPOFFER`; the client keeps retransmitting `DHCPDISCOVER` and the user sees Wi-Fi connected with no network. The cost of the short lease is renewal traffic every half lease and less tolerance of a server outage, which is why desk scopes keep long leases.

go deeper

for a junior

Recall that leases outlive the visit because devices rarely release them, and that an empty pool means new clients get no address at all.

for a middle

Estimate occupancy as arrival rate times holding time, and explain that the server sends no Offer when nothing is free.

for a senior

Size lease length per scope from visit length and arrival rate, monitor free-address counts, and weigh renewal load and outage tolerance.

for a principal

Set a lease policy across guest, desk and device scopes that balances address headroom, outage tolerance and the traceability of short-lived addresses.

## Why the guest pool runs dry A **lease** is the time for which a DHCP server promises an address to a client. RFC 2131 says the server guarantees not to reallocate the address within that time. The address comes back early only if the client sends **`DHCPRELEASE`**, and RFC 2131 itself notes that a client "will not normally relinquish its lease during a graceful shutdown". On guest Wi-Fi it is worse: a phone that walks out of the building sends nothing at all. So each guest holds an address for its **holding time**: the time it is on the network, plus whatever is left of its lease after it leaves. That is at most the visit plus one full lease, since the last renewal happened while it was still present. The number of addresses in use is then roughly > addresses in use ≈ arrivals per hour × holding time in hours ## Working the numbers Take a guest network that sees 1,500 different devices a day, arriving evenly over a 10-hour day (150 an hour), each staying about an hour, with a pool of 500 addresses. | Lease | Longest holding time | Addresses in use | Outcome | |---|---|---|---| | 24 hours | the rest of the day: nothing expires | grows by 150 an hour | full after 500 / 150 ≈ 3.3 h, about 3 h 20 min | | 1 hour | 1 h visit + 1 h lease = 2 h | at most 150 × 2 = 300 | 200 addresses to spare | If the doors open at 08:00, the 24-hour pool is exhausted around 11:20, matching "dry by late morning". Shortening the lease is the fix; enlarging the subnet is the other lever, and sizing it is subnet arithmetic rather than pool design. Devices that change their MAC address per network or over time make this worse: each new identity is a new client to the server, and the old lease lingers until it expires. ## What clients see when the pool is empty 1. The client broadcasts `DHCPDISCOVER`. 2. RFC 2131 section 4.3.1 says that if no address is available the server *may* report the problem to the administrator. There is **no "pool full" message**: the server sends no `DHCPOFFER`. 3. The client retransmits on a randomised backoff, about 4 s, then 8 s, doubling up to 64 s. 4. Many clients meanwhile configure an IPv4 link-local address, which works only on the local link. 5. The user sees Wi-Fi "connected" with no network. Clients already holding leases keep working, because renewing an existing lease needs no free address. Exhaustion therefore shows up on the server's side, in its logs and pool statistics, not as an error on the client. ## What a short lease costs - **Renewal traffic.** A bound client renews at T1, which RFC 2131 defaults to half the lease. A one-hour lease means a renewal every 30 minutes per guest; with about 150 guests present at a time that is about 300 small exchanges an hour, trivial for a server. - **Outage tolerance.** A one-hour lease reaches T2 (rebinding, default 0.875 of the lease) at 52.5 minutes and expires at 60. A DHCP outage of an hour drops guests off the network; a desk scope with multi-day leases rides out the same outage unnoticed. - **Address churn.** Short leases recycle addresses quickly, so tying a log line to a device needs the server's lease history for that exact time. ## Choosing lease length per scope The lease length is local policy: RFC 2131 has the server use a **locally configured default** when the client asks for none, and lets it grant or override a lease the client requests in option 51. That is why it is set **per scope**: - **Guest Wi-Fi**: short leases matched to the typical visit, so turnover keeps pace with arrivals. - **Desks**: long leases, typically days, so addresses stay stable and a server outage is invisible. - **Watch the pool, not just the lease**: alert on the server's free-address count before it reaches zero, because clients will not report it.

  • The guest pool is exhausted but staff laptops on the same scope keep working. Why?
    They already hold leases. Renewing at T1 extends an existing binding and needs no free address, so bound clients are untouched. Only clients that need a new address, new arrivals and devices whose leases expired, get no offer and keep retransmitting their Discover.
  • Why not just make every scope's lease very short?
    Short leases trade outage tolerance for turnover. With a one-hour lease clients start rebinding at 52.5 minutes and lose their address at 60, so a DHCP outage of an hour takes the scope down, and addresses churn so often that logs need lease history to read. Desk scopes have no turnover problem, so long leases cost them nothing.

saying these in an interview costs you the question

  • Devices hand their address back when they leave, so lease length barely matters.
  • When the pool is empty the server sends a DHCPNAK saying there are no addresses.
  • Exhaustion means the first leases expire 24 hours in, when the pool overflows.
  • A shorter lease halves the address count because clients renew more often.
  • Clients already holding leases are cut off as soon as the pool is exhausted.