When a device receives the wrong address, DHCP reservation not working troubleshooting should begin with evidence rather than repeated reboots. A reservation tells a DHCP server to offer a chosen address to a particular client identity. If the identity, server, lease, or scope does not match, the device may receive another address.
This guide follows a safe order. You will first confirm what the client requested, then identify which server answered, inspect the lease, review scope rules, and clean up stale data. This evidence-based DHCP reservation not working troubleshooting process avoids changing several settings at once. Each change can hide the original cause.
Understand what a DHCP reservation controls
DHCP, or Dynamic Host Configuration Protocol, automatically supplies network settings. Those settings usually include an IP address, subnet mask, gateway, and DNS servers. A reservation links an address to a client identifier, commonly a MAC address.
The reservation does not force a device to use the address in every situation. It only affects offers from the DHCP server that owns the reservation. A device on the wrong VLAN may contact another server. A manually configured address may never request a lease. Some clients also identify themselves differently across wired, wireless, docking, or virtual interfaces.
Keep these distinctions clear:
- Reservation: a server-side preference for a specific client.
- Lease: the server’s time-limited assignment of an address.
- Static address: a value entered directly on the device.
- Client identifier: the value the server uses to recognize the requester.
For general evidence-based troubleshooting, the Google SRE troubleshooting guidance is a useful reference. Record observations before testing a hypothesis.
Start with the client identity
The most common mistake involves reserving the wrong identity. One laptop may have separate Ethernet, Wi-Fi, VPN, virtual, and privacy-related interfaces. Phones may randomize their wireless MAC address. Virtual machines may present their own virtual adapter identity.
On the affected device, record the interface that connects to the target network. Note its current IP address, MAC address, gateway, and whether the address came from DHCP. Do not copy the MAC address from an inactive adapter or a nearby switch record.
Then compare that value with the reservation. Check the format carefully. Some systems display hyphens, colons, or no separators. The format usually does not matter, but every hexadecimal character does. For a Windows wireless client, compare these details with the Windows Wi-Fi diagnostic sequence when adapter identity or connection state is unclear.
Check for changing client identifiers
A wireless privacy feature can create a different MAC address for a network. This improves privacy, but it can defeat a reservation tied to the device’s hardware address. Confirm the current setting for that network before disabling anything.
Similarly, docking stations and USB Ethernet adapters may have different identities. If the reservation should follow the person rather than one adapter, consider whether a reservation is the right design. Ask the network administrator to approve any change.
Record the confirmed identifier before continuing with DHCP reservation not working troubleshooting. This prevents later lease checks from using the wrong adapter.
Confirm which DHCP server answered
A reservation applies only on the server where it exists. The network may contain a router, firewall, wireless controller, Windows server, Linux server, or managed service that can answer DHCP requests. If two servers answer, clients may receive inconsistent addresses and settings.
Inspect the client’s lease details for the DHCP server address, when the operating system exposes it. Compare that address with the device where the reservation was created. A mismatch explains many apparently ignored reservations.
Next, review the network design. Identify the DHCP server for the client’s VLAN or subnet. Relay agents can forward requests to a central server, while separate VLANs may use different scopes. A reservation in the office scope will not apply to a guest network scope.
Look for unauthorized or forgotten DHCP services. Common sources include an old router left in access-point mode, a lab server, an imaging system, or a newly installed firewall. Do not disable a suspected server during business hours without confirming its role and preparing a rollback.
If a switch or access point appears involved, compare its link and VLAN state with a working device. The switch port troubleshooting guide provides a safe way to review those network-layer details.
Inspect the current lease state
DHCP clients do not necessarily request a new address every time you refresh a screen. They may renew an existing lease, retain a valid address, or wait before retrying. Therefore, a reservation change may not appear immediately.
Record the current address and lease expiration first. Then use the operating system’s normal release and renew process, if appropriate for that device and network. A release briefly removes the client’s address, so avoid it during a critical session or on equipment that cannot tolerate interruption.
After renewal, verify four values:
- Assigned IP address matches the reservation.
- DHCP server matches the expected server.
- Subnet mask and gateway match the intended scope.
- Lease time and renewal time look reasonable.
If the client keeps its old address, clear only the relevant client lease or restart the network interface through an approved maintenance step. Do not reboot switches, routers, or servers as a first response. A restart may temporarily change behavior without explaining why.
On the server, check the active lease table. Search by client identity and by address. An old lease may show a different hostname or identity. That information helps you distinguish a stale record from an active conflict.
Use the same evidence sequence for DHCP reservation not working troubleshooting after each approved renewal. Compare the result with the prior lease instead of relying on a single refresh.
Review scope settings and address availability
A scope is the pool of addresses and rules for a subnet. Inspect whether the reserved address belongs to the correct scope. The address should match the client’s VLAN, subnet, and intended gateway.
Check exclusions, blocked addresses, and address conflicts. Some DHCP platforms refuse to offer an address that appears in use. Others may mark it as declined after detecting a response from another device. Review the server’s event log or lease status before deleting anything.
Also inspect option settings. A client may receive the correct reserved address but still appear broken because it receives the wrong gateway, DNS server, or network boot option. Compare the affected lease with a working device in the same scope.
Scope capacity matters as well. A full pool can produce symptoms that resemble a reservation failure. Count active leases and confirm that the reservation does not overlap another reservation or an excluded range.
For segmented networks, verify DHCP relay behavior and helper settings. A relay may direct requests to a different server than expected. Changes to relay configuration affect many clients, so capture the current settings before editing them.
Find stale reservations and conflicting records
Stale data can remain after equipment replacement, adapter changes, or a network redesign. Search the DHCP server for duplicate reservations, old hostnames, and the same client identity in multiple scopes. Also search for the desired address in the lease table.
Do not delete a record simply because its hostname looks old. Confirm its MAC address, lease activity, device owner, and network location. A renamed device may still be legitimate.
When you identify an obsolete reservation, document it before removal. Export or photograph the relevant settings if the platform supports that process. Then remove only the stale entry, renew the affected client, and confirm the result.
Some platforms replicate DHCP data between members or appliances. A change on one node may not reach the active node immediately. Verify synchronization status and identify which node currently serves the client. This is especially important after failover or hardware replacement.
Use a controlled test and document the result
Test with one known client and one known reservation. Capture its identity, VLAN, old address, new address, DHCP server, lease times, and relevant timestamps. If possible, compare the result with a similar working device.
A packet capture can show the DHCP exchange. The usual sequence includes Discover, Offer, Request, and Acknowledgment. The capture can reveal whether the client requested a particular address, which server offered it, and whether the client accepted the offer. Capture only the affected segment and follow your organization’s privacy rules.
After the fix, test connectivity to the gateway, internal services, DNS, and any application that depends on the reserved address. Confirm that another device does not already use the address. Finally, record the reservation owner, purpose, network, client identity, and date reviewed.
That record makes future DHCP reservation not working troubleshooting faster because the original identity, scope, and server are already documented.
When the reservation still does not work
Escalate when the client identity changes unexpectedly, multiple DHCP servers remain possible, relay behavior is unclear, or the server logs show declines or conflicts. A managed firewall, controller, or hosted DHCP service may also hide important lease details.
Tech Rescue Ops LLC can help trace the client, server, VLAN, lease, and scope without making uncontrolled network changes. Professional remote assistance is appropriate when the issue affects several devices or when testing could interrupt business operations.