Understanding network infrastructure · Part 1 · How does my PC get ready to communicate?
How does a laptop get an IP address when it connects?
From an unconfigured client's Discover to renewal, relaying, and conflict detection: the life of a lease
A laptop joining a new network needs more than an IP address. It also needs a subnet mask, default gateway, and DNS server. The DHCP client and server exchange Discover, Offer, Request, and Acknowledgment messages; the resulting configuration remains valid for a limited lease. This article follows the process from initial allocation through T1 and T2, renewal and rebinding, expiration, relaying, and reservations—the full life of a lease.
Without an IP address, how does a client find a DHCP server?↑
A newly connected client has no usable IPv4 address, so it sends DHCPDISCOVER as a broadcast. DHCP uses UDP: the server uses port 67, and the client uses port 68.
A broadcast normally does not cross a router. When the client and server are on different subnets, a gateway's DHCP relay receives the request, forwards it to the server, and identifies the client's network.
A client's initial DHCPDISCOVER can use source IP 0.0.0.0 and destination 255.255.255.255. The transaction ID and client identity help match a later Offer to the request. With neither its own subnet nor the server's location known, the client starts with a broadcast. If this packet never appears on the access VLAN, check the server and relay only after checking the client, port, and VLAN assignment.
Within the same broadcast domain, a server can respond directly. In an enterprise network, a gateway relay usually forwards the request to a central server instead. Traffic between the relay and server then follows a route as unicast. There is no contradiction between saying that a broadcast cannot cross a router and using another subnet's DHCP server. At the broadcast boundary, the relay forwards a new packet that also identifies the client's network.
Seeing a Discover does not prove that it reached the server. VLAN assignment, port security, DHCP snooping, and relay configuration determine the broadcast path. In the first capture, record the client interface's Discover times and retry intervals. Then find the same transaction at the server or relay. This separates a failure to respond from a failure to deliver the request.
Sources for this section IETF RFC 2131
What to look for in the diagram The diagram connects the flow above to the BOOTP-compatible fixed header, the DHCP option TLV structure, and xid, yiaddr, chaddr, message type, and other packet fields. Compare the field names and example values to see which header fields and options contain the information described in the text.
↔ Scroll horizontally to explore the diagram.
Choose an offer, then wait for an ACK to confirm the lease↑
The server includes an available address and subnet mask, router, DNS server, lease time, and other options in DHCPOFFER. Multiple servers may respond, so an Offer is not yet the final configuration.
The client announces its chosen server and address in DHCPREQUEST. When the selected server sends DHCPACK, the client applies the configuration. An unacceptable request may receive DHCPNAK, requiring the process to restart.
The client chooses one Offer and announces the requested address in DHCPREQUEST, identifying the selected server. Sending this initial Request as a broadcast lets the other servers see that they were not chosen and return their proposed addresses to the pool. The selected server rechecks policy and address state, then sends ACK or NAK. DORA is more than four names to memorize: it moves through discovery, an announced selection, and final approval.
An ACK carries more than an IP address. The prefix, default gateway, DNS server, lease time, and other options shape the client's actual connectivity. A valid address with the wrong DNS or gateway can still cause an outage, so merely confirming an ACK is not enough. Compare the server's lease record with the client's applied options. Also check whether the client detected an address conflict and sent DHCP Decline.
If an ACK provides an address but lacks a correct router or DNS option, the client may have an address yet be unable to reach a service. Do not judge DHCP success from the IP address alone: check the prefix, router, DNS, lease time, and the interface using them.
Sources for this section IETF RFC 2131
What to look for in the diagram The diagram shows a typical initial exchange of Discover, Offer, Request, and ACK. The choice of broadcast or unicast can vary with client state and implementation. Follow the numbered messages between client and server in the DORA exchange to compare the yiaddr field with the requested-address and lease-time option examples.
↔ Scroll horizontally to explore the diagram.
Before a lease expires, why does T1 trigger renewal?↑
A DHCP address is not a permanent transfer of ownership; it is permission to use an address for a limited lease. The client normally reaches its lease's T1 and asks the original server for renewal. If that succeeds, it can keep using the address.
If renewal fails after T1, reaching T2 allows other servers to respond through rebinding. Without an ACK before expiration, the client must stop using the address and start over. The T1 and T2 values may be supplied by the server as options.
For a typical 8-hour lease with no timer overrides from the server, the client can begin at T1, around 4 hours, contacting the original server with a unicast DHCPREQUEST for renewal. No reply at T1 does not mean the address is immediately abandoned. At T2, around 7 hours, a broadcast rebinding attempt seeks another server's help. The client waits for a valid ACK until the 8-hour lease expires. Check actual T1 and T2 options and implementation behavior.
When the link environment changes—for example, a laptop wakes on a different network—remaining lease time alone does not justify keeping the old address. The client may enter INIT-REBOOT and ask the server whether that address is still valid. During troubleshooting, go beyond a single packet and identify whether the client is performing initial binding, renewal, or rebinding. That state explains why a DHCPREQUEST can have different destinations and options.
The T1 and T2 ratios, retry intervals, and client behavior can vary with options and implementation. An outage may be hidden if you inspect only the current address: an earlier ACK may have supplied a still-valid lease. Record the lease start, T1, T2, expiration, and renewal packets together. This explains why a server failure affects new clients differently from existing clients.
Sources for this section IETF RFC 2131
What to look for in the diagram The example below uses a lease time of 8 hours with no separate T1 or T2 options. The timeline marks the start of the lease, T1 renewal (4 hours), T2 rebinding (7 hours), and lease expiry (8 hours). The notes explain how the request destination changes and when to stop using the leased address if renewal fails.
↔ Scroll horizontally to explore the diagram.
Across VLANs: reaching a DHCP server when broadcasts cannot↑
In a large network, each VLAN need not have its own DHCP server. A central server handles requests that relays receive from clients as broadcasts and forward as unicast. Fields such as giaddr identify the originating subnet.
The server uses that information to choose an address from the correct scope. A wrong relay address or policy can make a healthy server choose another scope or fail to find a response path. Where Option 82 is used, the relay can add circuit and port identifiers; define the trust boundary clearly.
The server reads the relay's giaddr to identify the subnet and scope, then sends the response back toward that relay. If the relay has multiple interfaces or uses VRFs, its source address and routing context for reaching the server matter. Even if a request appears in the server log, an incorrect giaddr may prevent scope selection, leaving no Offer to send.
Option 82 Circuit ID and Remote ID can identify an access port or relay device for policy decisions. Do not blindly trust values inserted through an untrusted port. Document how switch DHCP snooping and relay policies add, preserve, or remove each option. With redundant relays, two gateways may forward the same request. Capture traffic to verify how the server handles duplicates and which relay receives the response.
A relay does not make the DHCP server part of the local broadcast domain. The client VLAN, relay interface, server route, and return path must all be correct. Use captures at different points to distinguish an incorrect giaddr, a missing helper configuration, Option 82 policy rejection, or a server with no route back to the relay network.
Sources for this section IETF RFC 2131 · IETF RFC 3046
What to look for in the diagram Follow the DHCP relay as it adds giaddr and Option 82 Circuit ID and Remote ID, then forwards the request across subnets to the server over a Layer 3 path. Compare giaddr 10.10.1.1, Circuit ID Port 5, and Remote ID Switch-01 MAC in the numbered relay steps with the explanation of address-pool selection and policy decisions.
↔ Scroll horizontally to explore the diagram.
The same IP every time: reservations versus conflict detection↑
A DHCP reservation maps a client identifier or MAC address to a specific IP so the client repeatedly receives that address. It makes allocation predictable within the server-managed DHCP pool. It is not the same as manually configuring an address on the device.
The server's records do not guarantee the actual network state. A bad manual configuration or a restored device may use the same address. A client can perform ARP-based conflict detection before applying an address, and a server may offer ping checks, but behavior and defaults vary by product.
A reservation's match key is not necessarily one physical MAC address. Depending on the environment, it may use a client identifier, a DUID, or relay information. Replacing a NIC or booting through PXE can change the identifier and prevent the same device from matching its reservation. Rather than stopping at 'the MAC is registered,' check what the server read from the actual Request: which client ID did it compare with which reservation?
Conflict detection helps find unexpected address use already present on the network. Silence in response to an ARP probe or ping does not prove that an address is free: a sleeping device, blocked ICMP, or an isolated VLAN may hide it. The primary defense is to manage the dynamic pool, manual allocations, and reservations so that the same address is not assigned to different devices, and keep IPAM consistent with the lease database. Treat probes as the final safety net.
Check client identification too. Some environments use a MAC address; others use a client identifier or DUID-related value. A replacement device, dock, or changed virtual interface may therefore miss its expected reservation. Correlate IPAM ownership, the DHCP lease, and ARP or neighbor evidence to distinguish an incorrect server allocation from another device using the address without authorization.
Sources for this section IETF RFC 2131 · IETF RFC 5227
No address? Find where the exchange stops between Discover and ACK↑
Scenario: Only VLAN 30 clients are using 169.254.0.0/16 addresses; other VLANs work normally.
- Capture traffic to check whether the client sends DHCPDISCOVER.
- On VLAN 30's gateway, verify the relay destination and source interface.
- Check the server logs for receipt of the request and selection of the correct scope.
- If an Offer comes back, check for blocking by switch security features or along the UDP 67/68 path.
- After the fix, verify the full DORA exchange and the received mask, gateway, and DNS options.
When Discover repeats, first identify the capture point. Seeing only an endpoint's outbound packet proves only that it created the request. Check whether the request crossed the access VLAN, reached the relay, and arrived at the server, using evidence from each point. If an Offer returns, follow its path back to the endpoint as well.
Align both captures with the logs using the transaction ID, client identifier, giaddr, and offered IP. Recording them together lets you trace one exchange through a mix of clients' broadcasts. After the fix, do not stop at seeing an IP address. Verify the lease time, mask, gateway, DNS, and route against the design. Test through renewal too: initial DORA can succeed even when renewal fails and causes a disconnect hours later.
Listing message names alone will not locate the failure. Follow the same transaction at the client, relay, and server to separate broadcast delivery, pool policy, return path, and client configuration problems.
Sources for this section IETF RFC 2131 · IETF RFC 3046 · IETF RFC 5227
FAQ↑
If there are two DHCP servers, does a client get two addresses?
Is a longer lease always better?
Which is better: a DHCP reservation or a static IP?
Glossary↑
Sources and verification
- IETF RFC 2131 — DHCP messages and the lease lifecycle
- IETF RFC 3046 — DHCP Relay Agent Information Option
- IETF RFC 5227 — IPv4 Address Conflict Detection
- IETF RFC 3442 — DHCP Classless Static Route Option
DORA is the typical initial lease exchange. The choice of broadcast or unicast, client identification, and conflict-detection behavior can vary with state and implementation.