skip to content

After a DHCPACK, a laptop's ARP check finds the leased address already in use; what must the DHCP client and server each do next?

level: seniorimportance: should knowfreq 15%

answer

  1. a final check after the Ack
  2. sender IP zero in the ARP request
  3. the client declines, the server quarantines
  4. pause before trying again
  5. someone is squatting in the pool

basics

~20 s

The client must broadcast a DHCPDECLINE naming the address and the server, then should wait at least ten seconds before restarting with a new Discover. The server must mark that address not available and should alert its administrator.

solid answer

~50 s

RFC 2131 has the client make a final check after the `DHCPACK` — typically an ARP request for the address with its own sender IP set to `0.0.0.0`, so a failed check pollutes nobody's ARP cache. If another host answers, the client MUST send a `DHCPDECLINE`: it is broadcast, `ciaddr` is zero, the requested IP address option names the conflicting address and the server identifier names the server that assigned it. The client then restarts configuration, waiting at least ten seconds so a recurring conflict does not become a loop. The server MUST mark the address not available and SHOULD notify the administrator of a likely configuration problem — typically a statically addressed device inside the pool, or two servers handing out the same range. The server's own optional ICMP echo probe before offering can miss a host that does not answer ping.

go deeper

for a junior

Remember that DHCPDECLINE comes from the client and means the address it was given is already used by another host.

for a middle

Explain the two checks — the server's optional ICMP echo before offering and the client's ARP check after the Ack — and what a DHCPDECLINE carries.

for a senior

When declines repeat, find the squatter: a static device inside the pool or a second server on the same range, and watch how long the server keeps declined addresses out of service.

for a principal

Weigh where conflict detection should live: the server's echo probe delays new offers and can be switched off, while relying on clients alone finds conflicts only after an address is assigned.

## Two checks, two sides DHCPv4 guards against handing out an address that some other host is already using, and RFC 2131 splits that duty between server and client. | Check | Who | When | How | RFC 2131 strength | |---|---|---|---|---| | Server probe | the server | before offering a newly allocated or reused address | e.g. an ICMP Echo Request to the address | SHOULD; administrators MAY be allowed to disable it | | Client check | the client | after the `DHCPACK`, before using the address | e.g. ARP for the address | SHOULD | RFC 2131 tells the server not to check the address again when it answers the Request. The two checks catch different things. The echo probe is optional, runs earlier and only finds hosts that answer ping. The client's ARP check runs at the moment of use, on the link where the address will live, and a host already using the address on that link will normally answer ARP for it. ## What the client's ARP check looks like RFC 2131 asks the client to broadcast an ARP request for the assigned address with **its own hardware address as sender and `0.0.0.0` as sender IP**, so that if the address is taken, no other host's ARP cache is rewritten to point the address at the newcomer. RFC 5227 (IPv4 Address Conflict Detection) later named this an **ARP Probe** and fixed its timing; the probe's own mechanics are ARP's subject. If nothing answers, the client is configured, and RFC 2131 says it SHOULD broadcast an ARP reply announcing its new address so stale cache entries are cleared. ## The DHCPDECLINE message If the check finds the address in use, the client **MUST** send a `DHCPDECLINE`. Per RFC 2131's tables: - It is a **client** message — the counterpart of the server's `DHCPNAK`, never the other way round. - It is **broadcast**: the client is declining the very address it would otherwise send from. - `ciaddr` is `0`; `flags` is `0`; the `xid` is one the client selects. - The **requested IP address** option MUST carry the conflicting address. - The **server identifier** option MUST name the server that assigned it. - A text message option SHOULD explain the problem; parameter requests and lease time MUST NOT appear. ## What happens next 1. The laptop on the office VLAN, `10.40.8.0/24`, receives a `DHCPACK` for `10.40.8.57` from server `10.40.8.5`. 2. Its ARP check gets a reply: a printer with a hand-set address already uses `10.40.8.57`. 3. The laptop broadcasts a `DHCPDECLINE` naming `10.40.8.57` and server `10.40.8.5`. 4. The server **MUST mark the address not available** and **SHOULD notify the administrator** of a possible configuration problem. 5. The client restarts configuration, but SHOULD **wait at least ten seconds** first, to avoid excessive traffic if the conflict keeps recurring. 6. A new `DHCPDISCOVER` draws offers of other addresses, and the bind completes. RFC 5227 adds a backstop for a server that keeps assigning a conflicting address: after **10 conflicts** (`MAX_CONFLICTS`) on an interface, a host must limit itself to **one new address attempt per 60 seconds** (`RATE_LIMIT_INTERVAL`). ## Diagnosing a run of declines A single decline is the protocol working. A server log full of them is a design problem: - **A static device inside the pool.** Find the host answering ARP for the address, then readdress it or exclude its address from the pool — exclusions belong to pool and scope design. - **Two servers handing out the same range.** Each server believes the address is free; whichever assigns it second causes the conflict. Dividing pools between servers is a scope-design decision. - **The server's echo probe is disabled** or the squatter ignores ping, so conflicts are only found by clients. - **Quarantined addresses shrinking the pool.** RFC 2131 says the server must mark a declined address not available but sets **no duration**; how long it stays out of service, and how it is returned, is the server implementation's choice. ## Mistakes that cost points - Calling `DHCPDECLINE` a server message, or confusing it with `DHCPNAK`. - Saying the declined address returns to the pool after a lease time — the RFC defines no such rule. - Treating the server's ping probe as making the client's check redundant. - Saying the client unicasts the Decline from the conflicting address.

  • If the DHCPv4 server already pinged the address before offering it, why does the client check again?
    The two checks differ. The server's ICMP echo probe is optional, can be disabled, runs before the Offer and only finds hosts that answer ping. The client's ARP check runs after the Ack, on the link where the address will be used, and a host using that address there will normally answer ARP. RFC 2131 makes both a SHOULD.
  • What keeps a DHCPv4 client from looping if a faulty server keeps assigning the same conflicting address?
    RFC 2131's wait of at least ten seconds slows each cycle, and the server MUST mark a declined address not available, so a compliant server moves on. RFC 5227 adds a cap: after 10 conflicts on an interface, a host may attempt at most one new address per 60 seconds.
  • What should an operator do when a DHCPv4 server keeps logging declines for the same addresses?
    Find who answers ARP for those addresses, then readdress the device or exclude its address from the pool, and check whether a second server hands out the same range. Because RFC 2131 sets no time for which a declined address stays unavailable, check how the server returns quarantined addresses before the pool runs short.

saying these in an interview costs you the question

  • The server sends a DHCPDECLINE when the client's address is already taken.
  • After a conflict the client keeps the address and lets ARP sort it out.
  • The client unicasts the DHCPDECLINE using the conflicting address as its source.
  • RFC 2131 returns a declined address to the pool after one lease time.
  • The server's ping probe makes the client's ARP check unnecessary.