A DHCPv4 relay agent forwards every client broadcast to two servers; what happens to the duplicate offers, and what must relay and servers do to make it work?
answer
- both servers answer the Discover
- the Request names one server
- same server set for every message
- the other server reads a decline
- ranges that never overlap
basics
~20 sBoth servers offer and the relay delivers both; the client takes one and broadcasts a DHCPREQUEST naming it as server identifier. The relay must send that Request to both servers, which must never offer the same addresses.
solid answer
~50 sWith two server addresses configured, the relay sends each request to both, so a client usually receives two `DHCPOFFER`s. It picks one (RFC 2131 leaves the strategy to the client) and broadcasts a `DHCPREQUEST` carrying option 54, the **server identifier**, of the chosen server. RFC 1542 requires the relay to send every message from a client to the same set of destinations, so both servers see that Request: the named server commits the binding and sends `DHCPACK`, and the other treats the Request as notice that its offer was declined. That is also why a round-robin relay breaks DHCP. Because nothing in DHCP lets the two servers share lease state, they must not offer the same addresses: give each a non-overlapping part of the range, an operating convention, or run them as a failover pair, which only an expired Internet-Draft defines.
go deeper
Recall that a relay can list several servers, that each of them answers, and that the client accepts one offer by naming its server in the Request.
Explain option 54 in the selecting Request, why the unchosen server reads it as a decline, and why an offer commits nothing.
Show the rules that keep it working, namely the same destination set per client, no round robin and disjoint ranges, and what a server failure does to existing leases.
Weigh split ranges against a failover pair defined only by an expired draft: address efficiency, survivor capacity, dependence on one implementation and the cost of a partitioned pair.
## Why a relay lists two servers In the reserved campus, one central DHCPv4 server pair, `10.0.0.11` and `10.0.0.12`, serves forty VLANs. Each VLAN's gateway runs a relay agent, and each relay is configured with **both** server addresses, so that losing one server does not stop new clients getting an address. RFC 1542 §4.1.1 makes the relay's destination configurable and suggests a list of addresses. The relay does not choose between the servers; it copies each request to every destination on the list. ## The exchange with two servers 1. The client broadcasts a `DHCPDISCOVER`. The relay stamps `giaddr`, increments `hops` and sends one copy to each server. 2. Each server that has a free address in the subnet `giaddr` names sends a `DHCPOFFER` to the relay, and the relay delivers both to the client. 3. The client chooses. RFC 2131 §4.2 lets it use any strategy: take the first offer, or collect several and compare. It then broadcasts a `DHCPREQUEST` with the chosen server's address in option 54, the **server identifier**, and that offer's address in the requested-IP-address option. 4. The relay sends that Request to both servers. RFC 2131 §3.1 requires the Request to reuse the Discover's `secs` value and broadcast address precisely so that relays forward it to the same set of servers. 5. The named server commits the binding and answers `DHCPACK`. The other one, per RFC 2131 §3.1, treats the Request as notice that the client declined its offer. An offer commits nothing. RFC 2131 says a server SHOULD NOT reuse an address it has offered and may use an implementation-specific timeout before releasing it, so the losing server's offered address is held briefly and then freed. ## The relay's rule: the same destinations for every message from a client RFC 1542 says a relay MUST use the same destination, or set of destinations, for all messages it relays from a given client, and it explains why with a real failure: a relay that rotated each new message round-robin across its servers. With DHCP, that sends the Discover to one server and the Request to another, so: - the server that made the offer never sees the Request and never commits; - the server that receives the Request finds another server named in option 54 and treats it as a decline; - the client gets no `DHCPACK` and starts again. Load spreading is still allowed if it is per client: RFC 1542 suggests hashing the client's hardware address to pick a destination set. RFC 5107 adds that a relay using its server-identifier-override sub-option SHOULD forward all messages, renewals included, to all servers. ## The servers' rule: never offer the same address The two servers run no protocol with each other. If both owned the whole of `10.20.120.0/24`, each could lease the same address to a different client. The options: | Approach | Whose rule | How duplicates are avoided | Cost | |---|---|---|---| | Split range | an operating convention; ratios such as 80/20 are a habit, not an RFC | each server owns a disjoint part of the range | a survivor can only use its own part | | Failover pair | `draft-ietf-dhc-failover-12`, an expired Internet-Draft, never an RFC | the partners exchange lease state | both servers must implement the draft; a partner that cannot be reached is hard to tell from one that has failed | | One active server | none | only one server holds the pool | no redundancy | RFC 2131 also contains a rule for this situation: a server that receives an `INIT-REBOOT` Request for a client it has no record of MUST stay silent, "for peaceful coexistence of non-communicating DHCP servers on the same wire". ## What the operator sees - Each server logs offers for many clients that it never commits. That is normal with two helpers. - Relayed request traffic doubles, as do offers. - Renewals do not go through this machinery: a bound client renews at T1 by unicasting to the server identifier it was given. If that server is down, the client rebinds at T2 by broadcast, which the relay sends to both servers, and RFC 2131 lets the survivor extend the lease only if it has local administrative authority to do so. ## Misconceptions - **"The client sends `DHCPDECLINE` to the server it rejects."** `DHCPDECLINE` reports an address already in use after an accepted offer; a rejected offer is signalled by the Request naming someone else. - **"The relay forwards only the first offer."** A relay keeps no such state; it delivers every reply. - **"Two servers with the same range are safe, because clients probe the address."** A client SHOULD probe, but the probe misses a holder that is switched off.
- Why must a DHCPv4 client's selecting DHCPREQUEST reuse the Discover's secs value and broadcast address?RFC 2131 requires both so that relay agents forward the Request to the same set of servers that received the Discover. RFC 1542 lets a relay use `secs` as a factor in deciding whether to relay, so a Request with a different `secs` or destination address could be handled differently from the Discover. Keeping both identical means the unchosen server sees the decline and the chosen one can commit.
- If the DHCPv4 server that granted a lease fails, what happens to that client?Its renewal at T1 is unicast to the dead server and goes unanswered. At T2 it broadcasts a rebinding `DHCPREQUEST`, which the relay sends to both servers. RFC 2131 lets the survivor extend the lease only if it has local administrative authority, which shared lease state, as in a failover pair, provides. With split ranges it usually has none, and the client eventually loses the lease and starts again with a Discover.
saying these in an interview costs you the question
- The client sends a DHCPDECLINE to the server whose offer it rejects.
- The relay forwards only the first offer and drops the duplicate.
- Round-robin across the helper addresses spreads DHCP load safely.
- Two servers can share one range because clients ARP-probe each address.
- DHCP failover is a standard protocol defined in RFC 2131.