When two DHCP servers both answer a laptop's DHCPDISCOVER, how does the client choose one, and why is its DHCPREQUEST still broadcast?
answer
- one message, several audiences
- the losing server is listening too
- server identifier names the winner
- selection is left to the client
- same secs, same broadcast address
basics
~20 sThe client may pick any offer, for example the first; RFC 2131 sets no rule. It broadcasts the DHCPREQUEST so every server hears it: the server identifier tells the chosen server to commit and the others that their offers were declined.
solid answer
~50 sRFC 2131 leaves the choice to the client: it may collect offers for a while and compare the parameters offered, or simply take the first or the server it used before. It then broadcasts a `DHCPREQUEST` with the chosen server's address in the server identifier, the offered address in the requested IP address, `ciaddr` zero and source `0.0.0.0`. Broadcasting is the point. A server not named in that identifier treats the Request as the client declining its offer and can free the address; the named server commits the binding and answers with `DHCPACK`. The Request must also reuse the Discover's `secs` value and broadcast address, so that relay agents carry it to the same servers that saw the Discover. Because any server might be chosen, every server on the VLAN should hand out the same gateway, mask and resolvers.
go deeper
Remember that the client accepts exactly one offer and that its DHCPREQUEST is broadcast so every server hears which one won.
Explain the server identifier and requested IP address in the Request, why servers not named treat it as a decline, and why the choice among offers is the client's own.
On a two-server VLAN, trace inconsistent hosts back to the servers' differing parameters, and show from a capture which server identifier each client named.
Judge whether two uncoordinated servers on one VLAN buy enough redundancy to justify hosts configured by whichever offer wins, given DHCPv4 defines no protocol for servers to agree.
## The scenario: two offers on one VLAN An office VLAN, `10.40.8.0/24`, is served by two DHCPv4 servers, `10.40.8.5` and `10.40.8.6`. A laptop with no address broadcasts a `DHCPDISCOVER`; both servers hear it and both answer with a `DHCPOFFER`. The laptop now holds two proposals — `10.40.8.57` from the first server, `10.40.8.140` from the second — and must accept exactly one. Two questions follow: how it chooses, and why the message that announces the choice, the `DHCPREQUEST`, is still a broadcast when the client by now knows both servers' addresses. ## How the client chooses RFC 2131 deliberately leaves the choice open. - A client **may collect offers for a while** and pick the "best" one by the parameters offered, or simply take the **first** offer or the one from the **server it used before** — the RFC gives both as examples. - The time spent collecting and the selection rule are **implementation dependent**; nothing in the protocol ranks offers. (DHCPv6 differs: its Advertise messages carry a Preference option, RFC 9915.) - If no acceptable offer arrives, the client may send another `DHCPDISCOVER`. Because any server might win, RFC 2131 says it is important for **all servers to return the same parameters** — gateway, mask, resolvers — apart from the newly allocated address, and makes the administrator responsible for configuring them uniformly. Two servers that disagree produce hosts on one VLAN configured differently, depending on which offer arrived first. ## What the broadcast Request carries | Field or option | Value in this Request | Why | |---|---|---| | IP source → destination | `0.0.0.0` → `255.255.255.255` | no address yet; every server must hear it | | `ciaddr` | `0` | MUST be zero while selecting | | server identifier | `10.40.8.5` | names the winner; MUST be present | | requested IP address | `10.40.8.57` | MUST equal the chosen Offer's `yiaddr` | | `xid` | the Offer's `xid` | lets the client match the coming Ack | | `secs` | same as the Discover | keeps relayed copies on the same path | ## Why the Request is broadcast: three jobs in one packet 1. **It tells the losing servers.** A server not named in the server identifier uses the Request as notification that the client has declined its offer. There is no other message for this; the client sends no `DHCPDECLINE` to them, and RFC 2131 defines no server-to-server message. A unicast Request to `10.40.8.5` would leave `10.40.8.6` guessing. 2. **It tells the winner.** The server whose identifier appears commits the binding and answers with `DHCPACK` — or with `DHCPNAK` if it can no longer grant the address. 3. **It follows the Discover's path.** RFC 2131 requires the Request to use the same `secs` value and the same IP broadcast address as the original Discover, so that relay agents forward it to the same set of servers that saw the Discover. How relays do that is the relay agent's subject. The client's lack of an address is part of the picture — it still sends from `0.0.0.0` — but it is not the reason the RFC gives. The reason is that one message has to reach every server that made an offer. ## What the losing server does - It **sends nothing**: no Ack, no NAK. - It may return the offered address to its pool. RFC 2131 lets a server mark offered addresses unavailable while it waits, and says it SHOULD mark them available again if no Request from that client arrives. - An offer is not a reservation: servers SHOULD NOT reuse an offered address but may use an implementation-specific timeout before doing so. - If the client gives up and sends a fresh `DHCPDISCOVER`, the exchange starts over with a new `xid`, and the losing server may well make another offer — perhaps of the same address. ## Mistakes that cost points - "The client must take the first offer" — the first offer is one example, not a rule. - "The Request is unicast to the chosen server" — not in this exchange; it is broadcast. - "The losing server sends a NAK" or "the client sends a Decline to the loser" — neither happens. - Treating two servers with different gateway or resolver settings as harmless redundancy. - Assuming the winner is simply the server that answered fastest. The client may wait and compare offers, and its choice is visible on the wire only in the Request's server identifier.
- What does a DHCPv4 server that made an offer do if no DHCPREQUEST from that client ever arrives?Nothing announces it, so the server decides alone. RFC 2131 says it SHOULD mark the offered address available again if it receives no Request from that client. Offers are not reservations: servers SHOULD NOT reuse an offered address, but may apply an implementation-specific timeout before they do.
- Why must the offer-accepting DHCPREQUEST carry the same secs value and broadcast address as the DHCPDISCOVER?RFC 2131 makes both a MUST so that any relay agent between client and servers forwards the Request to the same set of servers that received the Discover; otherwise the server whose offer was chosen might never see the acceptance. How a relay picks its servers is the relay agent's subject.
- If the two DHCPv4 servers offer different gateways, what goes wrong?Each client's gateway then depends on whose offer it chose, which is implementation dependent, so hosts on one VLAN end up configured differently and some fail. RFC 2131 says it is important for all servers to return the same parameters except a newly allocated address, and leaves uniform configuration to the administrator.
Holding two job offers, you send one reply-all that says "I accept the first employer's offer". The first employer starts the paperwork; the second reads the same message and releases the post it was holding. A private reply to the first would leave the second still waiting.
saying these in an interview costs you the question
- RFC 2131 requires the client to accept the first DHCPOFFER that arrives.
- The DHCPREQUEST is unicast to the server whose offer the client accepted.
- The server that was not chosen sends a DHCPNAK to cancel its own offer.
- The client sends a DHCPDECLINE to every server whose offer it did not take.
- The Request is broadcast only because the client has no IP address yet.