DHCP Configuration

DHCP Relay: Getting DHCP Across Subnets

In the DHCP Fundamentals and DORA pages, we leaned on a key fact: early DHCP messages are broadcast-driven. That’s great inside one VLAN. It’s a problem the moment your DHCP server lives in a different subnet.

After this page, you should be able to:

  • Explain why DHCP breaks across VLANs without a relay
  • Describe what a relay actually does to the Discover/Request packets
  • Verify relay behavior using basic client commands and packet capture

The Problem: Broadcasts Don’t Cross Routers

DORA starts with broadcasts because the client has no IP and doesn’t know the DHCP server yet. But broadcasts generally stay inside a single broadcast domain (usually a VLAN). Routers and Layer-3 boundaries do not forward broadcasts.

Result: if your DHCP server is on a different subnet/VLAN than the client, the client’s DHCPDISCOVER never reaches the server. You’ll see Discover packets on the client side and no Offers coming back.

What a DHCP Relay Is

A DHCP relay is a helper function on a router, firewall, or Layer-3 switch that acts as a bridge between broadcast-only clients and a DHCP server on another subnet.

The relay listens for DHCP broadcasts on the client VLAN, then forwards them as unicast (or directed traffic) to the DHCP server. When the server responds, the relay sends the reply back to the client VLAN.

Important mental model:

The relay is not “a DHCP server.” It does not hand out addresses. It is a courier that forwards DHCP messages between networks.

How Relay Changes DORA (The Practical View)

Without relay, the Discover stays in the local broadcast domain. With relay, the router/L3 device forwards it to the DHCP server.

Client VLAN (10.10.20.0/24)              Router / L3 Switch               DHCP Server VLAN (10.10.10.0/24)
Client has no IP yet
0.0.0.0:68
     |  DHCPDISCOVER broadcast (255.255.255.255:67)                |
     |---------------------------> (relay hears broadcast)         |
                                      |                            |
                                      | forwards to server (UDP 67)|
                                      |--------------------------->|
                                      |                            |
                                      | receives DHCPOFFER         |
                                      |<---------------------------|
     |  relay delivers offer back into client VLAN                 |
     |<---------------------------                                 |
     |  client DHCPREQUEST (often broadcast)                       |
     |---------------------------> (relay forwards request)         |
                                      |--------------------------->|
                                      |<---------------------------|
     |<---------------------------  DHCPACK delivered to client     |

The Two Details That Actually Matter

1) The relay must be on the client’s Layer-3 gateway

Practically: DHCP relay is configured on the VLAN interface / SVI / routed interface that represents the client network (the default gateway for that subnet).

2) The relay must know the DHCP server IP

You point the relay at one or more DHCP server IP addresses. If that path is blocked (routing/firewall), DORA fails at Discover/Offer.

Ports & Traffic Shape (Quick Reference)

  • Client: UDP 68 → Server: UDP 67
  • Client side: Discover/Request are often broadcast inside the VLAN
  • Relay to server: forwarded traffic becomes unicast toward the DHCP server
  • If you see Discover on the client VLAN but nothing reaches the server, relay/routing/firewall is the first suspect

Common Relay Failure Patterns (and What They Mean)

Discover seen on client VLAN, no Offer

What you observe: Client broadcasts Discover; nothing comes back.

What it usually means: No relay configured, relay configured on wrong VLAN, or relay can’t reach the DHCP server IP.

Offer comes back, but client never gets an address

What you observe: Offer exists (maybe on server side), but no Ack on client.

What it usually means: UDP 67/68 blocked somewhere, or the client’s Request/Ack path is failing.

Client gets an IP, but can’t reach anything useful

What you observe: IP assigned, but no DNS resolution or no internet.

What it usually means: DORA worked, but DHCP options (gateway/DNS/mask) are wrong for that VLAN.

Only some clients work (randomness)

What you observe: Some devices get leases, others don’t.

What it usually means: Multiple DHCP servers responding, inconsistent relay targets, intermittent firewall drops, or scope exhaustion.

Hands-on: Prove Relay Is (or Isn’t) Working

You don’t need a fancy setup to verify relay behavior. You just need to force a DHCP renewal and observe what happens.

On a Windows client:

ipconfig /all

Check: DHCP Enabled, IPv4 Address, Default Gateway, DNS Servers.

Force a fresh DORA cycle:

ipconfig /release
ipconfig /renew

If renew fails and you end up with 169.254.x.x, DORA didn’t complete. That’s typically Discover/Offer failing across the L3 boundary.

Packet capture tip (quick)

If you capture on the client VLAN and see Discover but no Offer, relay is the likely culprit. If you capture near the DHCP server and never see forwarded requests, relay isn’t forwarding (or routing/firewall blocks it).

Key Takeaways

  • DORA starts with broadcasts, and broadcasts don’t cross routers by default.
  • DHCP relay is the bridge that forwards client DHCP messages to a server on another subnet.
  • Relay belongs on the client’s L3 gateway (SVI/routed interface for that VLAN).
  • Most relay issues show up as “Discover but no Offer” on the client VLAN.
  • Even with working relay, wrong DHCP options can make the network look broken.