skip to content

On a VLAN served by two DHCP servers, a laptop's DHCPREQUEST draws a DHCPNAK instead of a DHCPACK; what happened, and what does the client do next?

level: seniorimportance: should knowfreq 22%

answer

  1. only the named server answers
  2. the server could not honour it
  3. offers are not reservations
  4. a NAK goes to the whole link
  5. back to INIT, new Discover

basics

~20 s

The server named in the Request could no longer grant the offered address — RFC 2131's example is that it was allocated meanwhile — so it sent a DHCPNAK. The client discards the offer and restarts with a new DHCPDISCOVER.

solid answer

~50 s

During the bind, a `DHCPNAK` should come only from the server the client named in the Request's server identifier; the other server reads the broadcast Request as a decline and stays silent. RFC 2131 says the named server SHOULD send a NAK when it cannot satisfy the Request, for example because the requested address has already been allocated. That can happen because an Offer is not a reservation: servers SHOULD NOT reuse an offered address but may use an implementation-specific timeout, so a client that is slow to choose can lose it. The NAK carries the Request's `xid`, has `yiaddr` zero and is broadcast, since the client may not have a usable address. The client discards the offer, returns to INIT and sends a fresh `DHCPDISCOVER`; it does not fall back to the other server's offer, which its own Request already declined.

go deeper

for a junior

Know that DHCPNAK is a server refusing a Request, and that the client then starts again from a new Discover.

for a middle

Explain that only the server named in the Request answers, that offers are not reservations, and that a NAK is broadcast with yiaddr set to zero.

for a senior

Diagnose repeated NAKs on a two-server VLAN: pair NAKs and Requests by xid in a capture, confirm the server identifier, and compare the server's offer-holding timeout with client behaviour.

for a principal

Decide how long servers should hold offered addresses and how pools are divided when several servers answer one VLAN, since RFC 2131 leaves both to implementations and operators.

## Where a DHCPNAK can come from during the bind On an office VLAN, `10.40.8.0/24`, two DHCPv4 servers — `10.40.8.5` and `10.40.8.6` — both answered a laptop's `DHCPDISCOVER`. The laptop chose the first server's offer of `10.40.8.57` and broadcast a `DHCPREQUEST` naming `10.40.8.5` in the server identifier. Instead of a `DHCPACK` it received a `DHCPNAK`. Only one server can have sent that NAK legitimately. RFC 2131 has every server **not** named in the server identifier treat the Request as the client declining its offer, and those servers send nothing. The **server named in the Request** either commits the binding and sends `DHCPACK`, or — if it is unable to satisfy the Request — SHOULD send `DHCPNAK`. The RFC's own example of "unable to satisfy" is that **the requested address has been allocated** in the meantime. A NAK during the first bind is a different event from the NAK a laptop gets when it reboots on a new subnet and asks to keep its old address; that one belongs to the lease lifecycle. ## Why an offered address can vanish The NAK surprises people because they assume an Offer reserves the address. RFC 2131 says otherwise: - Servers **need not reserve** an offered address; the protocol only works more efficiently if they avoid giving it to someone else. - Servers SHOULD NOT reuse an offered address, but **may use an implementation-specific timeout** to decide when to reuse one. - A server MAY mark offered addresses unavailable, and SHOULD mark them available again if no Request arrives from that client. - Servers are not required to answer every Request; administrative policy (RFC 2131 §4.2) can also make a server refuse. So a client that collects offers for a long time, or retransmits its Request slowly, can find that the server has already handed the address to another client. ## Reading the NAK | Field or option | Value in a `DHCPNAK` | |---|---| | `op` | BOOTREPLY | | `xid` | copied from the client's `DHCPREQUEST` | | `yiaddr` / `ciaddr` | both `0` — nothing is being assigned | | `flags` | copied from the Request | | server identifier | MUST be present | | IP address lease time | MUST NOT be present | | a text message | SHOULD be present, explaining the refusal | | IP destination | `255.255.255.255` when `giaddr` is zero | The NAK is broadcast whatever the BROADCAST flag said, because the client may not have a correct address or mask and may not be answering ARP. Behind a relay agent the delivery path differs; that is the relay's subject. ## What the client does next 1. It matches the NAK's `xid` to its outstanding Request. 2. It **discards the offer** and returns to the INIT state — RFC 2131's state diagram takes a client in REQUESTING straight from `DHCPNAK` to INIT. 3. It does **not** fall back to the second server's offer: its own broadcast Request already told that server the offer was declined, and that server may have released the address. 4. It sends a fresh `DHCPDISCOVER` and collects new offers. RFC 2131 asks for a pause of at least ten seconds only after a `DHCPDECLINE`, not after a NAK. ## Diagnosing NAKs on a two-server VLAN - In a capture, pair each NAK with its Request by `xid`, and check that the NAK's server identifier matches the one the Request named. - Read the named server's log for why it refused; if the address now belongs to another client, compare its offer-holding timeout with how long clients take to choose. - If the same address is offered by both servers, expect address conflicts that surface as client `DHCPDECLINE`s rather than NAKs — dividing a pool between servers is a scope-design question. - A NAK carrying the identifier of a server the client did not name is not part of the exchange RFC 2131 describes; treat it as a separate problem for rogue-server defences. - A NAK that follows a Request the client had to retransmit several times points at delay: each retransmission waits longer, giving the server's offer timeout more chance to expire. ## Mistakes that cost points - Blaming the server that was not chosen: it reads the Request as a decline and sends nothing. - Expecting the client to fall back to the other offer. It discards its offer and starts over from Discover. - Confusing the NAK with a Decline: `DHCPNAK` is the server refusing a Request, `DHCPDECLINE` the client reporting that an assigned address is already in use.

  • Why doesn't the DHCPv4 client just take the second server's offer after a DHCPNAK?
    Its broadcast Request already told the second server that its offer was declined, so that server may have returned the address to its pool. RFC 2131's state machine sends a client in REQUESTING that receives a `DHCPNAK` back to INIT with the offer discarded, so it starts a fresh Discover and collects new offers.
  • Does a DHCPv4 client pause before rediscovering after a DHCPNAK, as it does after a DHCPDECLINE?
    RFC 2131 asks for a wait of at least ten seconds only after a `DHCPDECLINE`, to keep a repeating address conflict from looping. After a NAK the client simply restarts configuration from INIT; its new Discover follows the normal randomised retransmission rules if nothing answers.

saying these in an interview costs you the question

  • The server that was not chosen sends the DHCPNAK to withdraw its offer.
  • After a DHCPNAK the client takes the other server's offer instead.
  • An Offer reserves the address, so a NAK after it must be a server bug.
  • The DHCPNAK is unicast to the address the client requested.
  • The client answers a DHCPNAK by sending a DHCPDECLINE to the server.