skip to content

A campus adds a VLAN whose gateway relays DHCPv4 to the central server pair, but its clients get no address; what in the relay path explains it?

level: seniorimportance: should knowfreq 24%

answer

  1. walk the four legs in order
  2. relaying is off by default
  3. a pool for giaddr's subnet
  4. the server must reach giaddr on 67
  5. circuit-ID policy can refuse

basics

~20 s

Walk the relayed exchange leg by leg: relaying enabled on the new gateway, a pool on both servers for giaddr's subnet, a route and filter letting the servers reach giaddr on UDP 67, and no Option 82 policy refusing new circuits.

solid answer

~50 s

Split the exchange into its legs and find the one that goes quiet. On the gateway, RFC 1542 requires relaying to be off by default, so the new interface needs relaying enabled and both server addresses configured; a capture on its server-facing side shows whether the `DHCPDISCOVER` leaves with `giaddr` set. At the servers, allocation follows the subnet of `giaddr`, so the new subnet needs a pool on each, and a server that grants leases only to known Option 82 circuit IDs refuses new ones. On the way back, the server unicasts to `giaddr` on UDP port 67, so a missing route to the new subnet, or a filter that admits relayed requests but not replies to the relay, loses every offer. The return leg is the usual culprit, because rules written for client-to-server traffic forget it.

go deeper

for a junior

Recall the path: client broadcast, relay on the gateway, server, and back through the relay. A failure on any leg looks the same to the client.

for a middle

Name what each leg needs: relaying enabled with server addresses, a pool for giaddr's subnet, a route and an open UDP port 67 from the server back to giaddr.

for a senior

Localise before you change anything: capture on each side of the gateway and at the server; the first leg where the message vanishes names the fix, and the return leg is the usual one.

for a principal

Turn the incident into a standard checklist for every new VLAN, covering relay, pools on both servers, return route, filters and Option 82 policy, and decide which team owns each item.

## The exchange has four legs To the client, every failure looks the same: it retransmits its `DHCPDISCOVER` and never receives a `DHCPOFFER`. The protocol, though, splits the path into four legs, each with its own addressing, and each fails for its own reasons. | Leg | From and to | Addressing | Typical cause of silence | |---|---|---|---| | 1 | client to relay | `0.0.0.0` to `255.255.255.255`, UDP 68 to 67 | relaying not enabled on the new interface | | 2 | relay to server | unicast to each configured server, UDP 67, `giaddr` set | no server addresses configured; a filter toward the servers | | 3 | server to relay | unicast to `giaddr`, UDP 67 | no pool for the subnet; no route back to `giaddr`, or a filter closing UDP 67 to it | | 4 | relay to client | broadcast, or unicast to `yiaddr` at `chaddr`, UDP 68 | reply discarded at the relay, or a client that missed a unicast | In the reserved scenario, VLAN 140 is new, its gateway is `10.20.140.1/24`, and the servers are `10.0.0.11` and `10.0.0.12`. The other thirty-nine VLANs work, which already rules out most client-side explanations. ## Legs one and two: is the relay actually relaying? - **Relaying is opt-in.** RFC 1542 §4.1.1 requires a way to enable relaying and requires it to be **disabled by default**, and the destinations must be configured. A new VLAN interface relays nothing until both are set. - **`giaddr` is the receiving interface's address.** If the interface carries several addresses, RFC 1542 says the relay SHOULD pick one and use it consistently, so the servers see only that subnet. - **`hops` rarely matters here.** A single relay sends `hops = 1`. The threshold (at most 16; RFC 1542 suggests a configurable default of 4) only bites when relays are chained. - **Option 82 size does not drop requests.** If adding the option would exceed the relay's configured maximum, RFC 3046 says the relay forwards the request without it and counts an error. ## At the servers: is there anything to offer? RFC 2131 §4.3.1 allocates from the subnet that `giaddr` names. A new VLAN therefore needs a new pool, on **both** servers. If only one server has it, clients still get addresses but the redundancy is silently gone, which is easy to miss until that server is down for maintenance. A server that bases policy on Option 82 is the second suspect. RFC 3046 treats circuit IDs and remote IDs as opaque values matched exactly, lets a server base assignment policy on them, and gives refusing an unauthorised remote ID as an example. New access ports produce new circuit IDs, and until they are added to the policy the server has nothing it is allowed to offer. ## The return leg is the usual culprit The server never answers the client directly. With `giaddr` set, RFC 2131 §4.1 has it unicast every reply to `giaddr`, on UDP port **67**. That leg needs: - a route from the servers to `10.20.140.0/24`, or at least to `10.20.140.1`; - every filter on the path to permit the servers to send to UDP port 67 on the gateway's VLAN 140 address, a rule that sets written for clients-to-servers traffic often omit; - the gateway to recognise `giaddr` as one of its own interfaces. RFC 1542 §4.1.2 says a reply whose `giaddr` is not one of the relay's directly connected interfaces MUST be silently discarded. If the design forbids the servers from reaching client-side addresses, the link-selection sub-option of RFC 3527 lets the relay put a reachable address in `giaddr` and carry the client's subnet separately. ## Localising it before changing anything 1. Capture on VLAN 140: is the client's `DHCPDISCOVER` broadcast there? 2. Capture on the gateway's server-facing side: does a unicast to each server leave, with `giaddr = 10.20.140.1` and `hops = 1`? 3. At each server, in its log or a capture: did the request arrive, and did the server send a `DHCPOFFER`, and to which address? 4. Back on the gateway's server-facing side: does that offer arrive, addressed to `10.20.140.1`, UDP port 67? 5. On VLAN 140 again: does the relay deliver it, as a broadcast or as a unicast to the client's hardware address? The first step where the message disappears names the leg, and the table above names the likely cause. ## What it usually is not - **The clients.** Thirty-nine VLANs of the same clients work; a client bug would not pick one VLAN. - **The hop limit.** One relay, one hop. - **The `BROADCAST` flag.** It only shapes the relay's final delivery, and would not fail every client on one VLAN while sparing the others.

  • The new VLAN's gateway has a primary and a secondary subnet; why do DHCPv4 clients only get addresses from the primary's pool?
    A relay with several addresses on one interface SHOULD pick one and use it consistently as `giaddr` (RFC 1542), so the server only ever sees the primary subnet. RFC 2131 lets a server allocate from another subnet on the same link, but how it learns which subnets share a link is left to its configuration. Declare both subnets as one link on the server, or carry the subnet with the link-selection sub-option.
  • Which captures separate a DHCPv4 server that never received the request from a reply the relay never delivered?
    Capture on both sides of the gateway and at the server. No relayed unicast with `giaddr` set leaving the gateway: the relay is not configured. Sent but never logged at the server: the forward path or a filter drops it. An offer sent but never arriving at `giaddr` on UDP 67: the return path. Arriving but absent from the client's VLAN: the relay discarded it.

saying these in an interview costs you the question

  • Routers relay DHCP by default once the VLAN interface is up.
  • If the server received the Discover, the problem cannot be on the network.
  • Raising the hops threshold will fix a single relay that gets no replies.
  • The server answers the client directly, so the route back to the gateway is irrelevant.
  • An oversized Option 82 makes the relay drop the client's request.