A DHCP reservation is a server-side rule that binds one IP address to one client identifier, usually a MAC address, so the DHCP server always offers that device the same address. In networking and address configuration, it combines the predictability of a static address with the central management of dynamic addressing.
The client itself still runs an ordinary DHCP exchange and receives a normal lease with options such as gateway and DNS servers. Only the address selection step on the server changes: instead of picking the next free address from the pool, the server looks up the reservation table first.
How a DHCP reservation works
A DHCP reservation works by inserting a lookup before pool allocation. When a DISCOVER or REQUEST message arrives, the server reads the client identifier and checks whether a reservation exists for it in the scope that matches the interface or relay address.
If a match exists, the server offers the reserved address in the DHCPOFFER and confirms it in the DHCPACK. The lease still has a normal lease time and renewal timers: the client renews at T1, about 50 percent of the lease, and rebinds at T2, about 87.5 percent. Because the binding never changes, a renewal always returns the same address.
The table below shows which identifiers servers commonly use to match a reservation and where each one is reliable.
| Identifier | Where it comes from | Reliability notes |
|---|---|---|
| MAC address | chaddr field of the DHCP message | Simple, but changes with NIC swaps and MAC randomization |
| Client identifier (option 61) | Sent by the client operating system | Stable per host, but some systems derive it differently |
| DUID (DHCPv6) | Generated by the client for IPv6 | Survives NIC changes; may change after reinstallation |
| Relay circuit ID (option 82) | Inserted by the relay switch port | Binds the address to a port, not to a device |
Reservation versus static address and dynamic lease
A reservation differs from a static address in where the configuration lives. A static address is typed into the device itself, while a reservation lives on the server and is delivered through the standard DHCP protocol, so gateway, DNS and other options stay centrally managed.
The comparison below places reservations between the two extremes of address configuration.
| Property | Static address | DHCP reservation | Dynamic lease |
|---|---|---|---|
| Where it is configured | On each device | On the DHCP server | On the DHCP server |
| Address stays the same | Yes | Yes | Usually, not guaranteed |
| Works when server is down | Yes | Only until lease expiry | Only until lease expiry |
| Gateway and DNS changes | Manual on each device | Automatic at renewal | Automatic at renewal |
| Typical use | Core routers, DHCP server itself | Printers, cameras, NAS | Laptops, phones, guests |
Related mechanisms in the same topic behave differently. SLAAC in IPv6 lets hosts build their own addresses from a router prefix, so a reservation in the DHCP sense does not apply there. ARP only maps an existing IPv4 address to a MAC address and plays no role in assigning it, although many servers send an ARP probe or ICMP echo before offering an address to detect conflicts.
Placing reservations inside or outside the pool
Reserved addresses should follow a deliberate addressing plan. Most server implementations allow a reservation either inside the dynamic range or outside it, and the choice affects how conflicts and capacity are handled.
The following decision table summarizes common layouts for a /24 subnet with the subnet mask 255.255.255.0.
| Layout | Example range | Advantage | Drawback |
|---|---|---|---|
| Reservations outside the pool | Pool .100-.199, reservations .20-.99 | Clear separation, easy auditing | Requires planning the split in advance |
| Reservations inside the pool | Pool .20-.250 with reserved entries | No range redesign needed | Reserved address may already be leased to another client |
| Static block plus reservations | Static .1-.19, reserved .20-.99 | Infrastructure survives a DHCP outage | Three ranges to document |
When a reservation is created inside the pool, the server excludes that address from dynamic allocation, but an existing lease held by another device stays valid until it expires. Checking the lease table before creating the reservation avoids a temporary duplicate assignment.
When to use a DHCP reservation
A reservation is the right choice when a device needs a stable, known address but should still receive its settings from the network. Typical candidates are devices that other hosts reach by IP address or that firewall rules and port forwards refer to.
- Network printers and scanners, whose drivers often store an IP address.
- IP cameras and recorders, referenced by video management software.
- NAS appliances and home servers, targeted by port forwarding rules.
- Access points and smart building controllers, managed from a central console.
- Hosts whose address appears in firewall rules or allow lists.
Core infrastructure is the exception. The DHCP server, default gateway and DNS servers should keep manual static addresses, because they must work before any lease exists and while the DHCP service is unavailable.
Common problems and their fixes
Most reservation failures come from an identifier that no longer matches what the client sends. The table lists frequent symptoms and their usual causes.
| Symptom | Likely cause | Fix |
|---|---|---|
| Device gets a pool address instead | Private MAC randomization enabled | Disable it for that network or match another identifier |
| Reservation ignored after NIC change | New hardware address | Update the reservation with the new MAC |
| Two devices share one address | Old dynamic lease not yet expired | Clear the lease or wait for expiry |
| Reservation works on one VLAN only | Created in the wrong scope | Recreate it in the scope that serves the device |
| Address changes after server failover | Reservations not replicated | Synchronize the reservation table on both servers |
A reservation is not a security control. Any device that spoofs the reserved MAC address can obtain the same lease, so access decisions should rely on authentication such as 802.1X, not on the fact that an address was reserved.
A plain-language summary
Think of the DHCP server as a hotel reception that hands out rooms to arriving guests. Usually each guest gets whichever room is free. A DHCP reservation is a standing booking: whenever one particular guest arrives, the reception gives that guest the same room every time.
The guest still checks in normally and receives the same welcome information as everyone else. The difference is that other people always know where to find that guest, which is exactly what printers, cameras and file servers need.
An example from practice
A small accounting office runs one subnet, 192.168.10.0/24, with the router acting as DHCP server. The dynamic pool covers .100 to .199. The office printer had been receiving a different address after every power outage, and staff repeatedly lost the ability to print because the driver pointed to the old address.
The administrator moved the pool boundary, then created reservations in the .20 to .49 block for the printer, the NAS and two IP cameras, each keyed to its MAC address. The gateway and DNS settings still came from DHCP, so a later change of DNS provider reached every device at the next renewal. After the change, printing survived every restart and the NAS port forward no longer broke. One camera later lost its reservation after a firmware update enabled a randomized MAC address, which was fixed by turning that feature off for the camera.