The access point has plenty of capacity. The DHCP scope has run out of chairs.
A client can associate and authenticate, then fail to receive a usable IPv4 address. To the user, the Wi-Fi is broken. The radio dashboard may be entirely happy with itself. Both observations can be true.
Address capacity is a WLAN dependency. Treat it as part of the design and acceptance conversation, especially for guest networks, busy venues and environments where devices arrive and leave throughout the day. This guide concerns DHCP for IPv4; IPv6 addressing and DHCPv6 have different behavior and need their own design.
Find the pool the client actually uses
Start with the affected client, its authentication outcome and the VLAN or subnet assigned to it. One SSID does not necessarily mean one pool. Policy assignments, location, tunneling and other architecture choices can direct different clients to different networks. A nearly empty pool elsewhere is reassuring only if the client can use it.
Document the client-traffic path, the relay or proxy role where present, the expected DHCP servers and the scope selected for that subnet. Include reservations and other devices that consume the same address space. Verify the effective configuration, not a diagram from before the last change.
Size for occupancy over time
Count available dynamic addresses after exclusions, reservations and any server-specific allocations. Then compare that number with observed lease occupancy through the busy period. Connected-client count alone can understate demand because a server can retain a lease after a device leaves.
Account for turnover, multiple devices per person, shared subnets, atypical events and reasonable growth. If the same pool supports wired or other wireless clients, include them. Record peak occupancy, free addresses, lease duration and the observation window. Avoid claiming that a theoretical headcount is a measured peak.
RFC 2131 describes DHCP leases and notes that correct operation does not depend on a client sending a release. A device leaving silently is therefore not proof that its address immediately returned to the available pool.
Choose a lease for the population
Shorter leases can return unused addresses sooner, but increase renewal activity. Longer leases generally reduce renewal frequency while retaining allocations for longer. The right duration depends on observed turnover, server and network resilience, and how long clients need to remain connected.
RFC 2131 describes renewal and rebinding before expiry. A client normally tries to renew with its original server, then seeks a server through rebinding if necessary. Timers can be configured; do not assume every implementation behaves identically. Test representative devices, including sleeping and intermittently connected endpoints, before making a broad change.
Shortening a lease does not repair a broken relay, unreachable server, incorrect subnet selection or missing return path. It may merely give the incident a different schedule.
Trace the exchange at the right boundaries
A useful investigation identifies the last exchange observed and where it was seen. Coordinate captures and use aligned timestamps. Depending on the architecture, the relevant points may include the client side, controller or gateway, relay and DHCP server.
- Confirm association and authentication, then establish the actual VLAN and client address state.
- Look for the client's DHCP discovery or request and determine whether it reaches the expected relay and server.
- Check the scope, exclusions, reservations, conflicts and server logs. An exhausted pool is one possible cause, not the definition of every missing offer.
- Trace the reply back through the appropriate path. A server response that never reaches the client is a different problem from no server response.
- Repeat with a representative device during the affected conditions. Correlate records without exposing credentials or unnecessary client identifiers in a shared report.
Cisco's wireless DHCP troubleshooting guide provides platform-specific examples of scope, relay, reachability and packet-tracing checks. The exact commands and forwarding path depend on the deployed platform and release.
Make changes deliberately
Before expanding a subnet, review routing, security policy, broadcast-domain implications, gateway and relay configuration, monitoring and any downstream dependencies. Before changing lease time, assess the address-reuse benefit against the renewal load and recovery behavior. Agree the change window, rollback conditions and test evidence with the responsible teams.
Acceptance should include a representative client obtaining the expected address and completing the intended workflow, plus a review of free-address headroom under realistic occupancy. A connected icon is useful. It is not the whole acceptance plan.
For a concise version of this discussion, see Ryan's LinkedIn post on DHCP scope capacity.
Primary references
- IETF RFC 2131: Dynamic Host Configuration Protocol
- Cisco: Troubleshoot DHCP client connectivity on a wireless controller
- Cisco: Troubleshoot DHCP in enterprise networks
Technical sources checked November 3, 2026. Validate the design against the actual client population, server configuration and platform documentation.