Summary Explains the DHCP lease acquisition process, the client state machine through the life of a lease including renewal and rebinding, and how DHCP relay via helper addresses allows clients to reach servers on other subnets.
DHCP allows a workstation to obtain an IP address, subnet mask, default gateway, DNS servers, and other configuration parameters automatically. The protocol operates over UDP — the server listens on port 67, the client on port 68.
The critical characteristic that shapes everything else about DHCP is that the client has no IP address when it starts. It cannot send a unicast packet to a server it does not yet know about, so the initial exchange relies on broadcast. Because routers do not forward broadcasts, this creates the need for DHCP relay, covered later in this note.
Lease acquisition is a four-message exchange, commonly remembered as DORA — Discover, Offer, Request, Acknowledge.
| Step | Message | Direction | Source / Destination |
|---|---|---|---|
| 1 | DHCPDISCOVER | Client to server | 0.0.0.0:68 to 255.255.255.255:67 |
| 2 | DHCPOFFER | Server to client | Server IP:67 to client (broadcast or unicast) |
| 3 | DHCPREQUEST | Client to server | 0.0.0.0:68 to 255.255.255.255:67 |
| 4 | DHCPACK | Server to client | Server IP:67 to client |
The client has no address, so it sources the packet from 0.0.0.0 and broadcasts to 255.255.255.255. The packet includes the client's MAC address in the chaddr field and a randomly generated transaction ID (xid) used to match responses to this specific exchange. The client may include a Parameter Request List (option 55) specifying which configuration options it wants, and may request a specific address (option 50) if it is trying to reclaim a previous lease.
Any DHCP server that receives the Discover and has an available address in a scope matching the client's subnet responds with an Offer. The Offer contains a proposed IP address in the yiaddr field, along with the subnet mask, lease duration, and any requested options.
If multiple DHCP servers exist on the segment, the client may receive multiple Offers. The client typically accepts the first one it receives.
The server decides whether to unicast or broadcast the Offer based on the broadcast flag in the client's Discover. Many clients set this flag because their IP stack cannot receive a unicast packet addressed to an IP they have not yet configured.
The client broadcasts a Request rather than unicasting it to the chosen server. This is deliberate — the broadcast serves two purposes. It confirms acceptance to the selected server (identified by the Server Identifier, option 54, inside the Request), and it implicitly informs all other DHCP servers that their Offers were declined, allowing them to return the offered addresses to the pool.
The selected server commits the lease to its database and sends a DHCPACK containing the final configuration. At this point the lease is active and the client configures its interface.
Before actually using the address, a well-behaved client sends a gratuitous ARP for its new address. If another host replies, the address is already in use and the client sends a DHCPDECLINE, then restarts the process. This is why duplicate address problems often manifest as clients that appear to obtain an address and then immediately lose it.
| Message | Purpose |
|---|---|
| DHCPNAK | Server refuses a Request — typically because the client asked for an address that is not valid on the subnet it is currently connected to |
| DHCPDECLINE | Client rejects an offered address, usually after ARP detects it is already in use |
| DHCPRELEASE | Client voluntarily gives up its lease before expiry, e.g. on a clean shutdown or ipconfig /release |
| DHCPINFORM | Client already has a static address but wants configuration options such as DNS servers or a WPAD URL |
The lease is not a one-time event. Once a client holds a lease it moves through a defined state machine driven by two timers derived from the lease duration.
| Timer | Default Value | State Entered | Behaviour |
|---|---|---|---|
| T1 | 50% of lease duration | RENEWING | Client unicasts a Request directly to the server that issued the lease |
| T2 | 87.5% of lease duration | REBINDING | Client broadcasts a Request to any available server |
| Expiry | 100% of lease duration | INIT | Client must stop using the address and restart DORA |
Immediately after the ACK, the client is in the BOUND state and uses the address normally. Both T1 and T2 are running.
At T1 — halfway through the lease by default — the client attempts to extend it. It unicasts a DHCPREQUEST directly to the original server. No broadcast is involved, which means no relay agent is required for renewal even if one was needed for the initial acquisition.
If the server responds with an ACK, the lease timers reset and the client returns to BOUND. This is the normal steady-state behaviour and is invisible to the user.
If the original server does not respond by T2 — 87.5% of the lease — the client assumes that server is unreachable or gone. It broadcasts a DHCPREQUEST, which any DHCP server able to serve that subnet can answer. This is where relay agents become relevant again, because the broadcast needs forwarding if the server is off-subnet.
If a different server responds and can honour the address, the client keeps it. If a server responds with a NAK, the client immediately drops the address and restarts DORA.
If no server responds by the end of the lease, the client must stop using the address entirely. It releases the interface configuration and returns to INIT, restarting the DORA process from scratch. On Windows clients this is the point at which an APIPA address in 169.254.0.0/16 may appear.
⚠️ Lease Duration and Outage Tolerance: The lease duration determines how long clients survive a DHCP server outage. With an eight-day lease, a client that renewed just before the outage has roughly four days before it even starts trying to rebind. With a four-hour lease, that window is two hours. Short leases are useful for high-turnover networks such as guest wireless but significantly reduce tolerance to server failure.
Because the initial DHCP exchange uses broadcasts, and routers do not forward broadcasts by default, a client on one subnet cannot reach a DHCP server on another. In most enterprise networks the DHCP servers are centralised, so a relay mechanism is required.
A router or Layer 3 switch configured with a helper address acts as a DHCP relay agent. When it receives a DHCP broadcast on an interface with a helper address configured:
giaddr (gateway IP address) field in the DHCP header with the IP address of the interface on which the broadcast was received.giaddr value to determine which scope to allocate from.giaddr address.The giaddr field is the mechanism by which a centralised server knows which subnet the client is on. This is the single most important concept in DHCP relay — the server does not know or care where the client physically is, only what value appears in giaddr.
The helper address is configured on the interface facing the clients, not the interface facing the server.
interface Vlan10
ip address 10.10.10.1 255.255.255.0
ip helper-address 10.100.1.50
For redundancy, multiple helper addresses can be configured. The relay agent replicates the packet to each configured address, so both servers receive the Discover and both may respond with Offers.
interface Vlan10
ip address 10.10.10.1 255.255.255.0
ip helper-address 10.100.1.50
ip helper-address 10.100.2.50
The ip helper-address command does not only forward DHCP. It enables forwarding of eight UDP services by default:
| Port | Service |
|---|---|
| 37 | TIME |
| 49 | TACACS |
| 53 | DNS |
| 67 | BOOTP / DHCP server |
| 68 | BOOTP / DHCP client |
| 69 | TFTP |
| 137 | NetBIOS name service |
| 138 | NetBIOS datagram service |
This is frequently unexpected. A helper address configured purely for DHCP will also silently relay NetBIOS and DNS broadcasts to the same destination, which can generate unwanted traffic and, in some environments, constitutes an information disclosure path.
Unwanted protocols can be disabled globally:
no ip forward-protocol udp 37
no ip forward-protocol udp 49
no ip forward-protocol udp 53
no ip forward-protocol udp 69
no ip forward-protocol udp 137
no ip forward-protocol udp 138
This leaves only UDP 67 and 68 forwarded, which is usually the intent.
A relay agent can optionally insert Option 82, which carries circuit and remote ID information identifying the specific port or device the request came from. This allows a DHCP server to make allocation decisions based on physical location rather than just subnet. It is also used by DHCP snooping on switches to validate replies.
Option 82 can cause problems if a server is not configured to expect it — some servers silently discard requests containing options they do not understand, producing a failure that looks like the relay is not working at all.
The helper must be on the SVI or routed interface that receives the client broadcast. Placing it on the interface facing the DHCP server does nothing. This is the most common relay misconfiguration.
If the interface has multiple IP addresses (a primary and one or more secondaries), the relay agent uses the primary address as giaddr. Clients on the secondary subnet will therefore be allocated addresses from the primary subnet's scope. Secondary addressing and DHCP relay interact badly and should generally be avoided together.
The relayed traffic is unicast UDP 67 from the relay agent's interface IP to the server, and unicast UDP 67 back. Firewall rules written for "DHCP" that permit broadcast traffic or expect port 68 on the return path will block relayed DHCP. The return traffic is server port 67 to relay port 67 — not port 68.
When two servers serve the same subnet, the usual approach is to split the range — commonly 80/20 or 50/50 — so both can offer without conflicting. Both servers receive every Discover via the replicated relay, and the client accepts whichever Offer arrives first. Servers with overlapping full ranges and no failover relationship will eventually issue duplicate addresses.
Where DHCP snooping is enabled on downstream switches, the uplink toward the relay agent and server must be configured as a trusted port. An untrusted port drops server-sourced messages, so clients see Discovers leave and nothing come back. Additionally, a switch with DHCP snooping enabled may drop relayed packets containing Option 82 arriving on an untrusted port unless ip dhcp snooping information option allow-untrusted is configured.
Because renewal at T1 is a unicast directly to the server, a broken relay configuration will not be noticed by clients that already hold leases. The fault only becomes visible when a client boots fresh, moves subnet, or reaches T2. This produces the characteristic symptom of a problem that appears to arrive out of nowhere on a Monday morning after a change made mid-week.
An MX can act as a DHCP server per VLAN or relay to an upstream server, configured per VLAN in the dashboard rather than per interface. Relay is only available when the destination server is reachable over a VPN tunnel or local subnet. See KBA-044 - Meraki MX — LAN Port Behaviour and Limitations for wider context on MX LAN behaviour.
show ip dhcp binding
show ip dhcp conflict
show ip dhcp server statistics
show ip interface Vlan10 | include Helper
debug ip dhcp server packet
On a Windows client:
ipconfig /all
ipconfig /release
ipconfig /renew
The lease obtained and lease expires timestamps in ipconfig /all output confirm the lease duration actually issued, which is not always the duration configured if a server-side policy has overridden it.