Articles
DHCP Interview Questions: Lease Renewal, Relays, and Missing Addresses
Practice DHCP interview questions with allocation packets, lease renewal and rebinding, relay paths, pool evidence, and missing-address troubleshooting.
A laptop receives an address on one VLAN but not another. The DHCP server is running, the pool has space, and somebody suggests restarting it. A stronger answer asks where the packet path breaks—and whether the client is allocating, renewing, or rebinding a lease.
DHCP interview questions reward state-aware troubleshooting. DORA describes initial allocation, but it does not describe every packet sent during an address’s lifetime. This guide follows one original lease timeline and one remote-VLAN incident from request to usable configuration. It covers DHCPv4; DHCPv6 and IPv6 SLAAC have different messages and assumptions.
Protocol facts are grounded in the RFCs. The address ranges, timestamps, pool counts, and packet observations are synthetic practice cases, not captures from a customer network.
Explain initial allocation without saying every DHCP message is broadcast
The familiar sequence is DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK. In initial selection, the client requests the chosen offer and identifies the selected server. Broadcast versus unicast behavior depends on client state, addressing, relay fields, and flags—not merely the message name. See RFC 2131.
An interview answer should state the starting condition: the client has no usable address, is trying to locate a server, and is not yet using an active lease. An offer is a proposal, not proof that the client finished configuration or that the resulting network path works.
Give the candidate this synthetic packet sequence: the client sends DISCOVER, receives two offers, sends REQUEST selecting server A, then receives A’s ACK. Ask which packet tells the other server that its offer was not selected. The selection REQUEST is useful precisely because the client’s choice matters beyond one point-to-point conversation.
Now remove the ACK. The observation “an offer arrived” cannot establish a completed lease. Investigate whether REQUEST left the client, whether the chosen server accepted it, and whether its reply returned. Preserve the transaction identifier and client identity so you do not combine unrelated attempts into an apparently complete DORA trace.
What do T1, T2, and expiry mean?
During renewal, the client normally unicasts DHCPREQUEST to its original server. If renewal fails until T2, it enters rebinding and broadcasts to seek another server. Without valid renewal, expiry requires it to stop using the address. Default T1 and T2 are one-half and seven-eighths of the lease duration, but servers can supply different values. See RFC 2131, section 4.4.5.
Do not confuse these with fixed global constants. RFC 2132 defines lease-time, renewal-time, and rebinding-time options in seconds. Read the actual values from the exchange and client state before assigning times to an incident.
For this original exercise, assume an eight-hour lease beginning at the request time 00:00, default timer fractions, negligible reply delay, and no timer fuzz. The simplified timeline is:
| Time | Client state or transition | Request target | Can it use the existing address? |
|---|---|---|---|
| 00:00 | BOUND after valid ACK | No renewal needed | Yes |
| 04:00 | T1: RENEWING | Original server, normally unicast | Yes, while the lease remains valid |
| 07:00 | T2: REBINDING | Broadcast to seek a server | Yes, until expiry |
| 08:00 | Lease expires without renewal | Return to allocation | No |
The point is to reason about state, not predict an exact operating system’s packet timestamp. Implementations and supplied options can alter timing. A client may also attempt renewal before T1. Make the simplifying assumptions visible.
Suppose a valid eight-hour renewal is obtained for a REQUEST sent at 04:00. The new simplified expiry is 12:00, not the original 08:00. RFC 2131 anchors the recalculated expiration to the request transmission time plus the granted lease duration; do not casually add the duration to ACK arrival time when precise accounting matters.
Now suppose the first successful renewal instead follows a REQUEST at 07:10. Under the same duration, expiry becomes 15:10. Record which request the ACK belongs to. An old ACK from an unrelated transaction is not evidence that the current lease was renewed.
How is renewal different from initial selection?
An already bound client knows its address and original server. Its renewal REQUEST has a different addressing context from an initial client selecting among offers. In renewal and rebinding, the existing address is carried in ciaddr; the initial selection request instead identifies the selected server and requested address. The state-specific fields are defined in RFC 2131’s client message rules.
A practical interview prompt is: “We see no new DISCOVER, so DHCP must be broken.” Ask whether the client still has a lease. If it is renewing, expecting a fresh four-message allocation sequence is the wrong test. The absence of DISCOVER can be consistent with healthy renewal behavior.
Likewise, an outage of the original server need not cause instant address loss. The remaining lease and later rebinding opportunity matter. But do not promise uninterrupted service indefinitely: a client that reaches expiry without renewal must relinquish use under the protocol contract.
Distinguish a DHCPNAK from silence. A negative response is evidence that the server rejects the requested configuration; silence leaves several possible causes, including request loss, reply loss, unavailable service, or deliberate lack of an applicable response. Diagnose the actual observation rather than applying one reset procedure to both.
Why does a remote VLAN need a relay?
Initial client broadcasts do not ordinarily travel through routers as general cross-subnet discovery. A relay receives the local request and forwards it toward configured servers, supplying relay information such as giaddr. That field helps the server identify the client network and directs the reply path. Relay behavior is specified in RFC 1542, which also applies to DHCP’s BOOTP-derived behavior.
Draw two different paths: client to relay on the local VLAN, and relay to server across routed infrastructure. Then draw the return path. A routing test from the server to its own gateway does not validate delivery back to the client’s access port.
For the original incident, assume local VLAN 10 clients obtain leases. Remote VLAN 30 clients send DISCOVER, the relay forwards requests, but no offer reaches those clients. The correct conclusion is narrow: the local service path works for one network; the remote path has not completed. It does not prove the VLAN 30 scope, relay configuration, or return path is correct.
| Capture or log point | Observation | Next distinction to make |
|---|---|---|
| Client VLAN | DISCOVER seen | Does the relay receive this same transaction? |
| Relay server-facing side | Forwarded request seen | Is the relay identity correct for the intended scope? |
| Server | Request arrives | Is an applicable address/configuration selected? |
| Server egress | Reply leaves toward relay | Does routing or filtering block the return path? |
| Relay client-facing side | Reply forwarded | Does the client receive and accept it? |
Use one transaction ID and client identity across observations. The relay-to-server and server-to-relay leg generally uses the server port, UDP 67; client delivery uses UDP 68. Do not create a firewall rule based on the assumption that every DHCP packet follows a simple client-68-to-server-67 pair regardless of relay direction.
If the server receives a request with the wrong giaddr, it may select the wrong scope or have no applicable scope. If the server emits the correct reply but it never reaches the relay, pool capacity is not the immediate missing evidence. Each observation moves the investigation to a different boundary.
How do you distinguish pool exhaustion from a broken packet path?
Pool exhaustion needs allocation evidence, not just the symptom “no address.” Inspect usable scope range, exclusions, reservations, active bindings, declined addresses, and server selection rules. A healthy server process does not establish an available address for this particular client network.
Use a synthetic capacity exercise: the scope has 200 usable candidates. Twenty are unavailable to this client class because of exclusions or reservations. There are 175 active bindings in the remaining range, with no other unavailable entries. The simplified remaining capacity is five, not twenty-five.
Then change one assumption: some reserved addresses already appear in the active-binding count. Blind subtraction can double count them. Compute the set union of unavailable addresses, not several overlapping totals. This is a data-accounting problem before it becomes a service restart problem.
Correlate the server’s decision for the exact client and relay network. Five free addresses elsewhere in the estate do not help a scope with no eligible candidates. Conversely, a reply generated with a valid offer shifts attention to its delivery and client acceptance rather than global pool statistics.
Do not free leases indiscriminately to make the dashboard greener. Deleting bindings does not prove clients stopped using those addresses, and it can create conflicts. Any capacity repair needs an approved operational procedure and an understanding of current lease ownership.
Does an ACK prove working connectivity?
No. It is evidence of configuration acknowledgment, not an end-to-end application test. Read the assigned address, subnet mask, router, DNS options, lease duration, and server identity. RFC 2132 defines these configuration options; they can be present yet inappropriate for the intended network.
For an original example, the client gets the expected address but a router option from a different subnet. The allocation path may have succeeded while default-route configuration is wrong. Another client has a valid route and can reach an IP address but fails hostname resolution. That observation points toward DNS configuration or reachability, not a missing lease.
Check address-conflict evidence and the local VLAN too. The same apparent address can be unusable because another device already occupies it or because the client’s access network is misconfigured. A server-side ACK log cannot establish what the client actually applied.
An IPv4 link-local address in 169.254/16 indicates a different addressing mechanism; RFC 3927 defines it. It is not proof of one specific DHCP cause such as exhaustion. Interpret it with the client’s logs and packet observations instead of treating it as a complete diagnosis.
Describe a safe missing-address investigation
First capture the symptom precisely: no address, expired address, wrong subnet, missing default route, or DNS-only failure. Record interface, VLAN, client identity, request times, and whether other clients on that same network succeed.
For an authorized Linux lab, basic state inspection might include:
ip -4 addr show
ip route show
journalctl -u NetworkManager --since '10 minutes ago'
The service name varies by distribution and network manager. These commands are examples for observation, not proof that every host uses NetworkManager. If packet capture is authorized, choose the interface and scope carefully and protect captured client identifiers and network details.
Follow the appropriate state path. An initial client needs the allocation exchange; a renewing client needs its REQUEST/ACK evidence and remaining lease; an expired client must not be assumed safe to keep using the address. Compare the failing transaction across client, relay, and server observations.
Only then propose a change. A missing relay destination, wrong scope, blocked return path, exhausted eligible pool, and rejected client configuration have different repairs. State the evidence for your hypothesis, the smallest authorized change, and the verification that would disprove it if wrong.
Success means more than “a new address appeared.” Verify the expected lease and options, absence of conflict, route and DNS behavior, and renewal under the intended path. Preserve the before-and-after record so a temporary rebinding success does not hide a still-broken original-server path.