Why can a DHCPv4 client not reach a server on another subnet by itself, and what does a relay agent do about it?
answer
- no address yet, so it broadcasts
- routers never forward 255.255.255.255
- the gateway re-sends it as unicast
- giaddr stamped with the receiving interface
basics
~20 sA DHCPv4 client with no address broadcasts to 255.255.255.255, which routers must not forward. A relay agent on the subnet's gateway catches that broadcast, writes its own interface address into giaddr and unicasts the message to the configured DHCP server.
solid answer
~40 sBefore it has an address, a DHCPv4 client sends its `DHCPDISCOVER` from `0.0.0.0` to the limited broadcast address `255.255.255.255` on UDP port 67, and RFC 1812 says routers MUST NOT forward limited broadcasts, so a server on another subnet never hears it. A **relay agent**, usually running on the VLAN's default gateway, accepts that broadcast, writes the address of the interface it arrived on into `giaddr` (only if `giaddr` is still zero), increments `hops`, and unicasts the message to each DHCP server address it has been configured with. The server uses `giaddr` to pick the pool for that subnet and sends its reply back to the relay, which delivers it to the client on the local segment. That is how one central server pair can serve dozens of VLANs.
go deeper
Recall the chain: no address, so the Discover is a limited broadcast; routers do not forward it; the gateway's relay agent stamps giaddr and unicasts it to the server.
Explain both jobs of giaddr, pool selection and return address, and the field rules: set only when zero, hops incremented, every other field left intact.
Show that you know relaying is off by default and needs its server addresses configured, so every new VLAN needs its gateway set up and a matching pool on the servers.
Frame relaying as what lets one central server pair serve every VLAN, and weigh that centralisation against its dependence on the routed path between gateways and servers.
## The problem: a client with no address can only broadcast A host that has just joined a network has no IPv4 address, no subnet mask and no default gateway, which are exactly what the **Dynamic Host Configuration Protocol** (DHCP, RFC 2131) is about to hand it. It also does not know where a DHCP server is. So its first message, the `DHCPDISCOVER`, goes out as: - IP source `0.0.0.0`, because RFC 2131 §4.1 requires a client that has no address yet to use it; - IP destination `255.255.255.255`, the **limited broadcast** address, meaning "everyone on this link"; - UDP destination port 67, the DHCP server port (replies to clients go to port 68). When the server sits on the same segment, that is enough: it hears the broadcast and answers. On a campus with one central DHCP server pair and forty VLANs, the servers sit on one subnet and the clients on forty others. ## What routers do with that broadcast A limited broadcast is confined to the link it was sent on. RFC 1812, the requirements for IPv4 routers, says in §5.3.5.1 that limited broadcasts MUST NOT be forwarded. The VLAN's default gateway receives the `DHCPDISCOVER` like every other host on the segment, and ordinary routing stops there. Without help, the client retransmits, never receives a `DHCPOFFER`, and eventually falls back to whatever its implementation does without DHCP. The same section of RFC 1812 anticipates the fix: a router may run a UDP service that *resends* such requests to other servers. For DHCP that service is the **relay agent**. RFC 2131 did not invent a new one; it reuses the **BOOTP relay agent** whose behaviour RFC 1542 §4 specifies, which is why the fields it touches carry BOOTP names. ## What the relay agent does to a request Relaying has to be switched on: RFC 1542 §4.1.1 requires a way to enable it and requires it to be **disabled by default**. Once enabled, the relay agent handles each client request (every client-to-server DHCP message is a `BOOTREQUEST` at the BOOTP layer) like this: 1. **Accept it despite the `0.0.0.0` source.** Routers normally discard packets from network 0 as "martians"; RFC 1542 §4.1 makes an exception for requests delivered to the relay agent. 2. **Check `hops`.** The client sets it to zero. A relay discards a request whose `hops` exceeds 16, or a lower configured threshold, for which RFC 1542 suggests a default of 4. 3. **Stamp `giaddr`.** If `giaddr` is zero, write the address of the interface the request arrived on. If it is already non-zero, a relay closer to the client set it, and it MUST NOT be changed. 4. **Increment `hops`.** 5. **Leave every other field intact**: the client hardware address (`chaddr`), the transaction ID and the options travel unchanged. A relay that also adds Option 82 appends it as one extra option. 6. **Send it to the configured destinations**, normally the unicast addresses of one or more DHCP servers, and never rebroadcast it on the interface it came from. So the broadcast that could not leave VLAN 120 becomes a unicast UDP datagram from the gateway to, say, `10.0.0.11`, carrying `giaddr = 10.20.120.1`. ## How the server and the relay finish the job `giaddr` does two jobs, and together they are why relaying works: | Job | Who reads it | Effect | |---|---|---| | Pool selection | the server | RFC 2131 §4.3.1: a relayed request gets an address chosen by the subnet of `giaddr`, so `10.20.120.1` selects the `10.20.120.0/24` pool | | Return address | the server | RFC 2131 §4.1: when `giaddr` is non-zero, the server sends its reply to the relay at that address, on UDP port 67 | The relay then delivers the `DHCPOFFER` or `DHCPACK` onto the client's segment, on UDP port 68. The client never needs to know a relay was involved: RFC 1542 §3.4 tells clients to ignore `giaddr` in replies, and in particular not to treat it as their router. The client learns its default router from the router option instead. ## Where the relay sits in a campus - One relay per client subnet, almost always on that subnet's default gateway, because the gateway is already attached to every VLAN it routes. - One pool per relayed subnet on the central servers, matching the `giaddr` each gateway will present. - Two server addresses on each relay when there are two servers, so both see every request; how the pair avoids handing out the same address is a server-redundancy question. The relay matters most for getting an address. A client that holds a lease renews at T1 by unicasting straight to its server; only if that fails does it broadcast again at T2, and that broadcast comes back through the relay. ## Common misconceptions - **"Just let the router forward broadcasts."** Routers must not forward limited broadcasts; the relay is a separate function that originates a new unicast. - **"The relay assigns the address."** It assigns nothing. It forwards, stamps `giaddr` and delivers replies; the server owns the pool. - **"The server picks the pool from the client's source address."** The client sends from `0.0.0.0`; `giaddr` is the subnet hint the header carries. - **"Relaying works the same way in IPv6."** A DHCPv6 relay wraps the client's message inside a dedicated relay message instead of stamping a header field.
- What does a DHCPv4 relay agent do with a request whose giaddr is already non-zero?It leaves `giaddr` exactly as it is: a relay closer to the client already wrote an address on the client's subnet, and RFC 1542 says a non-zero `giaddr` MUST NOT be modified. It still checks `hops` against its threshold, increments it and forwards the request to its own configured destinations, so pool selection stays tied to the client's subnet however many relays sit in the chain.
- Why not enable broadcast forwarding on the router instead of running a DHCP relay agent?The client sends to `255.255.255.255`, a limited broadcast, and RFC 1812 says routers MUST NOT forward those at all. Even a directed broadcast into the server's subnet would reach only servers on that one subnet and would tell them nothing about where the client lives. A relay originates a fresh unicast to any routable server and stamps `giaddr`, which gives the server both the pool and the return address.
A relay agent is a floor receptionist in an office tower. A visitor's call of "who handles room bookings?" cannot leave the floor, so the receptionist writes the floor number on the request and posts it to the central bookings office, which assigns a room on that floor and sends the answer back to the receptionist to hand over. The floor number, like giaddr, chooses both the room pool and where the answer goes.
saying these in an interview costs you the question
- The router forwards the client's broadcast to the server once DHCP is enabled.
- The relay agent hands out addresses from its own pool.
- The server picks the pool from the client's IP source address.
- The client installs giaddr from the reply as its default gateway.
- Every relay in a chain overwrites giaddr with its own address.