skip to content

Every DHCPv4 client on a relayed branch subnet extends its lease only at about 87.5%, never at 50%; what in the renewal path explains it?

level: seniorimportance: nice to knowfreq 10%

answer

  1. the two requests travel differently
  2. unicast skips the relay
  3. something blocks client-to-server unicast
  4. the broadcast at T2 still works
  5. server identifier override

basics

~20 s

A DHCPv4 T1 renewal is unicast from the client straight to the server, bypassing the relay; when that path is blocked, renewals fail and the lease is only extended by the T2 rebinding broadcast, which the relay does forward.

solid answer

~50 s

The two extension attempts take different paths. At `T1` the client unicasts its `DHCPREQUEST` from its own address to the address in the lease's `server identifier`; RFC 2131 notes no relay agent is involved, and the server unicasts its `DHCPACK` back to `ciaddr`. At `T2` the client broadcasts, the subnet's relay agent forwards the broadcast with `giaddr` set, and the reply returns through the relay. If anything blocks that direct unicast — a filter admitting only the relay's traffic to UDP port 67, a dropped reply to port 68, an unreachable `server identifier` — every renewal times out and the lease is extended only at `T2`. The cost is margin: clients run on one-eighth of a lease instead of half. The fixes are to permit that unicast both ways, or to have the relay use RFC 5107's Server Identifier Override sub-option so renewals come to it.

go deeper

for a junior

Recall that renewing at half the lease is unicast to the server and rebinding near the end is broadcast, so the two can take different paths.

for a middle

Explain why the renewal bypasses the relay agent, what addresses and ports it uses in each direction, and which reply the server sends where.

for a senior

Diagnose from logs: extensions clustered at seven-eighths of the lease with ciaddr set mean failed unicast renewals, and quantify the lost margin before proposing a fix.

for a principal

Choose between opening direct client-to-server paths and funnelling renewals through relays with the override sub-option, weighing filter sprawl against server support.

## The symptom Server logs for one branch show every lease extended at about seven-eighths of its duration, each request arriving through the branch's relay agent with `ciaddr` already filled in. No client ever seems to renew at the halfway mark, yet nobody loses an address. That pattern says the `T1` renewal is failing and the `T2` rebinding is rescuing it. ## Two requests, two paths RFC 2131 §4.3.2 and §4.4.5 send the two extension attempts very differently: | | `RENEWING` (from `T1`) | `REBINDING` (from `T2`) | |---|---|---| | Destination | the granting server's address, from the `server identifier` option | `255.255.255.255` | | Delivery | unicast, routed like any IP packet | broadcast, picked up by the subnet's relay agent | | Relay agent involved | no — "no relay agents will be involved" | yes; it forwards with `giaddr` set | | Server's reply | unicast `DHCPACK` to `ciaddr`, client port 68 | sent to the relay, which delivers it to the client | The initial exchange and the rebinding both depend on the relay. The renewal is the only DHCP traffic that needs a **direct, routed path in both directions** between each client's address and the server. ## What breaks the direct path - **A filter written for the relay only.** Rules that admit UDP port 67 from the relay's address to the server, built when the service was first set up, drop the same port from client addresses. - **A dropped reply.** The server's unicast `DHCPACK` to the client's port 68 is blocked on the way back, so the request arrives but the answer never does. - **An unreachable server identifier.** The address the server put in the `server identifier` option — on a multihomed server, perhaps the wrong interface — is not routable from the branch. ## What the clients actually do Each renewal fails the same way, and the RFC's timers carry the client through it: 1. At `T1` the client enters `RENEWING` and unicasts its `DHCPREQUEST`; nothing comes back. 2. It retransmits after half the remaining time until `T2`, never sooner than 60 seconds, and keeps failing. 3. At `T2` it enters `REBINDING` and broadcasts. The relay forwards it, a server with authority over the lease answers through the relay, and the client returns to `BOUND` with a fresh lease. Nothing visibly breaks, which is why the fault survives for months. ## Why it matters anyway The defaults are meant to leave a client half its lease to ride out trouble with its server, and the last eighth for a broadcast to any server. When renewals never work, only that last eighth remains: - On an 8-hour lease the safety margin falls from **4 hours** (8 − 4) to **1 hour** (8 − 7). - If the relay, the WAN link or the server is down during that final hour, leases expire and clients MUST stop using their addresses. - Clients spend three-eighths of every lease retransmitting unicast requests that cannot succeed. - Anything that relies on relay-inserted information only sees it on the initial exchange and the rebinding, because the unicast renewal never passes through the relay. ## Fixing it 1. **Permit the renewal path.** Allow UDP from client subnets to the server's port 67, and from the server back to port 68, and check that the `server identifier` the server advertises is reachable from every client subnet. 2. **Bring renewals through the relay.** RFC 5107 (Standards Track) defines the **Server Identifier Override** sub-option, code 11 in the relay agent information option. The relay puts its own address there; a server implementing it MUST copy that value into the `server identifier` it sends. Clients then unicast their renewals to the relay, which forwards them to the real server, so renewals use the same path as everything else. RFC 5107 describes this as letting a DHCPv4 relay work the way a DHCPv6 relay already does. Either fix restores renewal at `T1`, and the server logs should then show extensions at about half the lease.

  • On the affected DHCPv4 branch, how much lease is left when a client finally extends it, with an 8-hour lease and default timers?
    Rebinding starts at `T2`, 0.875 × 8 h = 7 h into the lease, so the client has 1 hour left at its first broadcast; with no answer its next try comes after half of that, at 30 minutes left. A healthy client renewing at `T1` would have 4 hours in hand.
  • Why does a DHCPv4 server need RFC 5107 support for the relay's override to work?
    The override is a request to the server: RFC 5107 says a server implementing the sub-option MUST put that address in the `server identifier` option of its reply and remember it for later messages. A server that ignores the sub-option advertises its own address, and clients keep unicasting their renewals straight to it.

saying these in an interview costs you the question

  • The relay agent must be dropping DHCPREQUEST messages that have ciaddr filled in.
  • The server is configured with T1 at 87.5% instead of 50%.
  • Renewals travel through the relay agent exactly like the initial exchange.
  • Since leases are still extended in time, nothing needs fixing.
  • Clients rebinding at T2 means the server sent them a DHCPNAK at T1.