Mental model
The DHCP DORA exchange (DISCOVER → OFFER → REQUEST → ACK — see DHCP) starts with the client knowing nothing — no IP, no gateway, no DNS. It sends a broadcast to 255.255.255.255 saying “any DHCP server out there, please give me an address.”
Broadcasts don’t cross routers. So if your client is in VLAN 10 (192.168.10.0/24) and your DHCP server lives in VLAN 99 (192.168.99.0/24), the broadcast dies at the first router/L3-switch boundary.
You have two options:
- Run a DHCP server in every VLAN. Awful — 50 servers to manage for 50 VLANs.
- Configure the router/L3-switch to relay DHCP broadcasts to a central server.
Option 2 is what every real network does. The configuration command is ip helper-address — a single line per interface.
The relay flow
VLAN 99 (192.168.99.0/24)
DHCP Server 10.99.99.5
▲
│ Unicast OFFER/ACK to 192.168.10.1 (GIADDR)
│
┌──────┴──────┐
│ L3 Switch │ "ip helper-address 10.99.99.5" on Vlan10
│ SVI Vlan10 = 192.168.10.1 │
└──────┬──────┘
│
│ Broadcast DISCOVER from VLAN 10
▼
┌──────────┐
│ Client │ PC in VLAN 10, no IP yet
└──────────┘
Step-by-step:
- Client broadcasts DISCOVER to
255.255.255.255. - L3 switch / router receives on the VLAN 10 SVI. Because of
ip helper-address, it doesn’t drop the broadcast. - Relay stamps GIADDR =
192.168.10.1(its own SVI IP for that VLAN). Unicasts the (now slightly modified) DHCP DISCOVER to10.99.99.5. - DHCP server uses GIADDR to find the right scope (the
192.168.10.0/24pool). Allocates an IP. Builds an OFFER. Unicasts it back to192.168.10.1(the GIADDR). - Relay receives the OFFER and broadcasts it into VLAN 10 (or unicasts, depending on the BROADCAST flag in the request).
- Client sends REQUEST (also broadcast) → relay forwards as before.
- Server sends ACK → relay forwards.
The client never knows it’s been relayed. To it, everything looks like a normal DORA — just with the gateway helping it find the server.
The config — one line
SW1(config)# interface Vlan10
SW1(config-if)# ip helper-address 10.99.99.5
That’s the whole feature.
You can have multiple helper addresses per interface:
SW1(config-if)# ip helper-address 10.99.99.5
SW1(config-if)# ip helper-address 10.99.99.6
The relay sends the DISCOVER to both. Whichever DHCP server answers first wins the race. Useful for DHCP redundancy.
What else ip helper-address forwards
Surprise — ip helper-address doesn’t only forward DHCP. It forwards a list of UDP broadcasts:
| Port | Protocol |
|---|---|
| 37 | Time |
| 49 | TACACS |
| 53 | DNS |
| 67 | DHCP / BOOTP server |
| 68 | DHCP / BOOTP client |
| 69 | TFTP |
| 137 | NetBIOS Name |
| 138 | NetBIOS Datagram |
You can tune the list with ip forward-protocol udp <port> (add) or no ip forward-protocol udp <port> (remove). Most engineers leave defaults and forget about it — until they wonder why TFTP boot requests are being relayed unexpectedly.
To disable all UDP forwarding except DHCP:
SW1(config)# no ip forward-protocol udp 37
SW1(config)# no ip forward-protocol udp 49
SW1(config)# no ip forward-protocol udp 53
SW1(config)# no ip forward-protocol udp 69
SW1(config)# no ip forward-protocol udp 137
SW1(config)# no ip forward-protocol udp 138
DHCP (67/68) is always forwarded when ip helper-address is set.
GIADDR — the field that makes it work
The DHCP server is single-armed (one IP, in VLAN 99). How does it know to allocate from the VLAN 10 scope rather than VLAN 99?
The relay stamps GIADDR (Gateway IP Address) in the BOOTP header before forwarding. The server reads GIADDR, finds the matching scope (the pool whose subnet contains GIADDR), allocates an IP from there.
This is why the relay’s IP on the client-side interface matters — it must be inside the scope subnet on the DHCP server.
If you have multiple IPs (HSRP virtual + real), you can tell the relay which to stamp:
SW1(config-if)# ip dhcp relay information option vpn
SW1(config-if)# ip dhcp relay source-interface Loopback0
Usually unnecessary; defaults work for 95% of deployments.
Option 82 — DHCP relay information
The relay can also insert Option 82 into the relayed DISCOVER — extra metadata like:
- The relay’s interface name (which switch port the client came in on)
- The relay’s MAC / IP
- A “Remote ID” identifying the client circuit
DHCP servers can use Option 82 for:
- Per-port IP assignment (every client on a given switch port gets the same IP)
- Audit / abuse tracking
- Securing against rogue DHCP servers
SW1(config)# ip dhcp relay information trust-all ! trust upstream Option 82
SW1(config-if)# ip dhcp relay information option ! insert Option 82
Pairs nicely with DHCP Snooping.
Verification
SW1# show ip interface Vlan10 | include Helper
Helper address is 10.99.99.5
SW1# show ip dhcp relay statistics
DHCP Relay Statistics:
Relay Messages: 142
...
SW1# show ip dhcp server statistics ! if server is on a Cisco device
SW1# debug ip dhcp server packet ! debug-level — careful in production
From the client side (Windows):
ipconfig /release
ipconfig /renew
ipconfig /all ! check the obtained values + scope
From a captured packet — open Wireshark, filter bootp or dhcp, look at the BOOTP header GIADDR field. If it’s 0.0.0.0, no relay happened. If it’s 192.168.10.1, relay worked.
Common mistakes
-
No
ip helper-addressconfigured. Clients in remote VLANs sit in APIPA range (169.254.x.x). The most common cause of “DHCP doesn’t work for that VLAN.” -
Helper points at the wrong server IP. Pointing at the wrong machine = silent failure. Verify the server has a working scope for the relay’s subnet.
-
Server has no scope for the relayed subnet. Server receives the relayed DISCOVER but has no pool matching GIADDR’s subnet → silently drops. Common after VLAN renumbering.
-
Routing missing between relay and server. The OFFER unicast from server to relay must be routable. A firewall between VLAN 99 and VLAN 10’s gateway must permit UDP 67/68.
-
Forgetting both directions. DHCP needs round-trip — server’s UDP 67 traffic must reach the relay too.
-
ip helper-addresson the wrong interface. It must be on the client-facing SVI/interface, not the server-facing one. -
Multiple servers with overlapping scopes. Both servers offer; client takes the fastest. If scopes overlap or contradict, you get inconsistent assignments. Configure split scopes or HA properly.
-
Forgetting Option 82 + DHCP Snooping interaction. If you enable DHCP Snooping on the switch and the upstream switch is the relay, Option 82 insertion can cause the server to reject — needs
trust-allor matching configs.
Lab to try tonight
- Build: client in VLAN 10, L3 switch as gateway, DHCP server in VLAN 99 (could be a Cisco router with
ip dhcp pool, a Windows server, ordnsmasqon a Linux VM). - Without
ip helper-address: client gets APIPA. Verify withipconfig. - Add
ip helper-address <server-ip>to the VLAN 10 SVI. Clientipconfig /renew→ gets IP from VLAN 10 scope. - Capture with
monitor captureon the L3 switch (or Wireshark on a SPAN port). Verify GIADDR is the SVI IP. - Stop the DHCP server.
show ip dhcp relay statistics— relay messages still increment (it tries) but no replies. Client falls back to APIPA after lease times out. - Add a second helper-address pointing at a second server. Both should appear in
show ip interface Vlan10 | section Helper. - Bonus: enable Option 82 (
ip dhcp relay information option). Capture again — Option 82 sub-options visible in the DISCOVER frame. - Bonus: enable DHCP Snooping. Observe how snooping cooperates with the relay (or doesn’t, if Option 82 trust isn’t configured).
Cheat strip
| Concept | Plain English |
|---|---|
| DHCP DISCOVER is broadcast | Stops at routers. Need a relay agent on the other side. |
ip helper-address <ip> | The single command that enables DHCP relay |
| GIADDR | Gateway IP Address field — relay stamps this for server to pick scope |
| Where to put it | On the client-facing gateway interface (SVI for L3 switch) |
| Multiple helpers allowed | Yes — first server to respond wins |
| Default forwards | DHCP + DNS + TFTP + TACACS + NTP — tune with ip forward-protocol udp |
| Option 82 | Relay-inserted metadata for fine-grained policy |
| Round-trip routing required | Server-to-relay path must work too |
| Where it fits | Every multi-VLAN network with a central DHCP server (which is most of them) |