skip to content

For an office's guest and desk DHCPv4 scopes, should server redundancy come from an 80/20 split scope or a failover pair, and what does each cost?

level: seniorimportance: should knowfreq 22%

answer

  1. who knows the other's leases
  2. rebinding needs a shared binding
  3. short leases drain the small share
  4. MCLT and PARTNER-DOWN
  5. the protocol never became an RFC

basics

~20 s

A split scope gives two unsynchronised servers disjoint parts of one range; it suits long desk leases. A failover pair shares bindings so either can renew any client, which short guest leases need, but its protocol is an expired draft.

solid answer

~50 s

In a **split scope** two servers share no state: each holds part of the range (80/20 is an operating convention, in no RFC). If the large server dies, its clients' unicast renewals at T1 go unanswered; at T2 they broadcast, but the survivor holds no binding and RFC 2131 lets a server extend a lease only with authority to do so, so at expiry they start over and change address. With multi-day desk leases a one-day outage touches only new arrivals; with one-hour guest leases every guest needs the small share within the hour. A **failover pair** keeps one binding database, so either server renews anyone. Its protocol is `draft-ietf-dhc-failover-12`, which expired in 2003 and never became an RFC: the MCLT bounds how far a lease may outrun what the partner knows, and leases shrink while the pair is apart. PARTNER-DOWN needs an operator or a safe-period timer.

go deeper

for a junior

Recall that DHCP needs two servers for redundancy and that a split scope gives each server part of the range without sharing leases.

for a middle

Explain why clients of a failed split-scope server change address at expiry, and what a failover pair shares to avoid it.

for a senior

Choose per scope by lease length and turnover, size the small share for the longest outage, and run the PARTNER-DOWN decision safely.

for a principal

Weigh an unstandardised failover protocol and its operational load against address changes, and set the redundancy policy for every scope class.

## Two answers to one failure RFC 2131 lets several servers answer the same client but defines no way for them to share leases; it only mentions sites with "a mechanism for maintaining consistency among leases managed by multiple servers". Operators use one of two designs. | | Split scope | Failover pair | |---|---|---| | Specification | None: an operating convention | `draft-ietf-dhc-failover-12`, an expired Internet-Draft, never an RFC | | Shared state | None | Both servers keep the same binding database | | Address ranges | Disjoint shares of one range, often 80/20 | Free addresses split between primary and secondary | | A client's renewals if its server dies | Fail: the other server has no binding | Succeed: the partner holds the binding | | Address change after an outage | Yes, if the outage outlasts the remaining lease | No | | Operational burden | Low | Higher: states, timers, the PARTNER-DOWN decision | ## How a split scope behaves Both servers are configured for the same subnet with **non-overlapping ranges**, for example 560 desk addresses on one and 140 on the other. Both can answer a `DHCPDISCOVER`, and the client takes one offer. RFC 2131 makes this coexistence safe: a server that receives an `INIT-REBOOT` request from a client it has no record of **MUST remain silent**, "necessary for peaceful coexistence of non-communicating DHCP servers on the same wire". When the large server fails: 1. Its clients reach **T1** (half the lease by default) and unicast a renewal to it. Nobody answers. 2. At **T2** (0.875 of the lease) they broadcast a rebinding request. The surviving server holds no binding, and RFC 2131 says a server **MAY extend a lease only if it has local administrative authority** to do so, so the lease is not extended. 3. At expiry the client starts again with a `DHCPDISCOVER` and gets a **new address** from the small share. **Desk scope, eight-day leases.** A client renews at day 4 and rebinds at day 7, so a server outage of a day expires nobody's lease. Only new arrivals and returning devices need the 140 spare addresses. The split works. **Guest scope, one-hour leases.** Every guest of the failed server rebinds at 52.5 minutes and expires at 60, so within an hour the *whole* guest population needs the small share. A 20% share cannot hold it. The split fails exactly where the lease is short. ## How a failover pair behaves The draft defines a **primary** and a **secondary** that exchange binding updates (`BNDUPD`, acknowledged with `BNDACK`). The key ideas: - **Lazy update.** A server may answer the client first and update its partner afterwards, so the partner can briefly know less than the client. - **MCLT (maximum client lead time).** The bound on that gap: a lease given to a client may exceed the expiry the partner has acknowledged by at most the MCLT. The primary configures it and sends it in the `CONNECT` message. - **Address pools.** The secondary asks for its share of free addresses with `POOLREQ`; the primary sends them in `BNDUPD` messages with the state `BACKUP`. - **COMMUNICATIONS-INTERRUPTED.** When the servers lose contact, each still renews *any* client, but only up to the MCLT beyond the latest expiry time the two servers had already exchanged, and new clients get addresses only from the server's own free share. Leases shrink toward "now plus MCLT". - **PARTNER-DOWN.** Entered by an external command or after an optional **safe period**. The server then waits the MCLT before using the partner's free addresses. If the partner was in fact still running, duplicate allocation becomes possible, which is why the draft gives operators the safe period to check. ## What each costs - **Split scope**: almost free to run, but clients change address after an outage longer than their lease's remaining time, and the small share must cover arrivals for the whole outage. - **Failover pair**: no address changes and no stranded share, but more state, an operator decision at PARTNER-DOWN, and a protocol with **no published standard**, so treat the pair as one implementation rather than mixing two. - **The 80/20 figure** is a convention from server documentation, not a protocol rule; size the small share from expected arrivals during the longest outage you plan for. ## A defensible answer for the office Desk scopes with multi-day leases can live with a split scope. The guest scope, with short leases and high turnover, needs a failover pair, or a split whose small share holds the whole guest population.

  • In a failover pair, why does the draft make a server wait the MCLT after entering PARTNER-DOWN before using the partner's free addresses?
    Because the partner may have leased some of its free addresses just before it failed, without telling the survivor. The MCLT bounds how long such a lease can run beyond what the survivor knows, so after waiting that long any such client has either expired or come to the survivor to renew.
  • Why is entering PARTNER-DOWN automatically after a safe period a risk?
    If the partner is still running and only the link between them failed, both servers may now allocate the same free addresses. The draft says that once the transition completes while the partner is not down, duplicate allocations become possible, so the safe period exists to give operators time to confirm the partner is really down.

saying these in an interview costs you the question

  • An 80/20 split scope is the ratio RFC 2131 specifies for primary and backup servers.
  • In a split scope the surviving server renews the failed server's clients at T2.
  • The DHCP failover protocol is a published IETF standard that any two servers can speak.
  • In a failover pair the MCLT caps every lease a client can ever receive.
  • Split scopes suit short-lease guest networks as well as long-lease desk networks.