Technical guide
DHCP Lease Expiry Explained
Understand renewal, rebinding and DHCP lease expiry. Find the failed exchange, restore connectivity and plan enough address capacity for your customers.
Plan your IPv4 expansionAn expiring lease should renew before it interrupts service
A DHCP lease reaching its renewal point does not normally disconnect a device. The client asks to extend the assignment while it can still use the address. When that exchange succeeds, the connection continues.
The important failure is an actual expiry without a successful renewal. The client must stop using the expired IPv4 address and obtain a valid assignment. Applications using that address can lose connectivity until the network configuration is restored.
Renewal, rebinding and expiry are different moments
| Stage | What the client does | What it means for service |
|---|---|---|
| Renewal (T1) | Requests an extension from the original server | The current lease is still valid |
| Rebinding (T2) | Broadcasts a request that another server can answer | There is still time to retain a valid assignment |
| Expiry | Stops using the expired address and starts acquisition again | Connectivity needs a new confirmed assignment |
Unless the server supplies different values, T1 defaults to 50% and T2 to 87.5% of the lease duration. For an eight-hour lease, those defaults mean renewal at four hours and rebinding at seven hours. These are protocol defaults, not a recommended lease length for every network.
Recognise what customers are experiencing
A failed renewal can appear as a device losing internet access, a remote session dropping, or an application becoming unreachable. Some clients may select a local fallback address; that does not restore normal routed access.
The timing is a useful clue, not a complete diagnosis. Compare the affected interface's lease timestamps with DHCP logs and network events. A DNS failure, wireless disconnection or upstream routing problem can produce similar symptoms.
Restore the assignment, then verify the service
- Check the client: confirm the interface, address, mask, gateway, DHCP server and lease timestamps.
- Check the access path: verify link state, VLAN and the DHCP relay for that subnet.
- Check the server: look for requests, replies, rejected requests and free addresses in the correct scope.
- Check the exchange: use logs or a packet capture to determine whether DHCPREQUEST messages receive DHCPACK replies.
- Check the customer result: after a valid assignment returns, test the gateway, DNS and the affected application.
Preserve a working remote path while troubleshooting. A forced release discards the current assignment and can cut off the session you are using to repair it.
Will the device get its old address back?
It may. A server can assign the same address again if it is available and suitable for that client. If it assigns a different one, applications that depended on the old address may need to reconnect or refresh their records.
Use reservations or another planned addressing method for devices that must remain easy to locate. A reservation supports consistent assignment; the client still needs a functioning DHCP exchange.
What happens to the address pool?
When an assignment ends, the server can make the address available for reuse according to its allocation rules. A disconnected device does not always send a release, so expiry provides a recovery mechanism for stale assignments.
Before shortening leases, check whether the pool is full of active devices or stale entries. Faster reuse can help with churn. It cannot serve more simultaneous unique-address users than the usable pool can support.
Reduce interruptions before the next busy period
- Monitor scope utilisation and renewal failures, not just server uptime.
- Keep relay and server paths reachable during maintenance.
- Use supported server redundancy with consistent lease state.
- Keep static assignments separate from dynamically allocated addresses.
- Test lease changes on a representative subnet and observe subsequent renewals.
Changing a default lease duration does not instantly rewrite every active lease. Review the settings the server actually gives clients, then confirm the expected behaviour through their next exchanges.
A device timer and your public IPv4 supply are separate
Your DHCP timer manages an assignment inside a network. A commercial IPv4 lease governs the capacity your organisation obtains from a provider. Ending one device assignment does not end that supply arrangement, and renewing a commercial lease does not repair a broken DHCP relay.
For the wider customer-service plan, combine reliable local allocation with address capacity ready for growth. LARUS offers Unlimited IPv4 through direct supply and LARUS Continuity, so expansion can be planned around the services you want to deliver.
Continue with how DHCP works or the difference between DHCP and IPv4 lease time.
Questions about DHCP lease expiry
Should I restart every device when a lease expires?
Find the renewal failure first. If a server, relay or exhausted pool is the cause, restarting clients does not repair that shared problem.
Does a short lease stop an unauthorised device?
No. A client may request another lease. Use authentication, segmentation and access controls to decide who can connect.
Does a longer lease make the internet faster?
No. It changes assignment and renewal timing. It does not increase bandwidth or fix a congested link.
The renewal behaviour is specified in RFC 2131, section 4.4.5.
Room for your next launch
Give your next customers room to grow.
Build with Unlimited IPv4 and LARUS Continuity. Plan the public address capacity for your next service, location or customer launch with LARUS directly.