DHCP Relay & IP Helper

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:

1. Run a DHCP server in every VLAN. Awful — 50 servers to manage for 50 VLANs.
2. 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:

1. Client broadcasts DISCOVER to 255.255.255.255.
2. L3 switch / router receives on the VLAN 10 SVI. Because of ip helper-address, it doesn’t drop the broadcast.
3. Relay stamps GIADDR = 192.168.10.1 (its own SVI IP for that VLAN). Unicasts the (now slightly modified) DHCP DISCOVER to 10.99.99.5.
4. DHCP server uses GIADDR to find the right scope (the 192.168.10.0/24 pool). Allocates an IP. Builds an OFFER. Unicasts it back to 192.168.10.1 (the GIADDR).
5. Relay receives the OFFER and broadcasts it into VLAN 10 (or unicasts, depending on the BROADCAST flag in the request).
6. Client sends REQUEST (also broadcast) → relay forwards as before.
7. 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:

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

1. No ip helper-address configured. Clients in remote VLANs sit in APIPA range (169.254.x.x). The most common cause of “DHCP doesn’t work for that VLAN.”

2. 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.

3. 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.

4. 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.

5. Forgetting both directions. DHCP needs round-trip — server’s UDP 67 traffic must reach the relay too.

6. ip helper-address on the wrong interface. It must be on the client-facing SVI/interface, not the server-facing one.

7. 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.

8. 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-all or matching configs.

Lab to try tonight

1. 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, or dnsmasq on a Linux VM).
2. Without ip helper-address: client gets APIPA. Verify with ipconfig.
3. Add ip helper-address <server-ip> to the VLAN 10 SVI. Client ipconfig /renew → gets IP from VLAN 10 scope.
4. Capture with monitor capture on the L3 switch (or Wireshark on a SPAN port). Verify GIADDR is the SVI IP.
5. 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.
6. Add a second helper-address pointing at a second server. Both should appear in show ip interface Vlan10 | section Helper.
7. Bonus: enable Option 82 (ip dhcp relay information option). Capture again — Option 82 sub-options visible in the DISCOVER frame.
8. Bonus: enable DHCP Snooping. Observe how snooping cooperates with the relay (or doesn’t, if Option 82 trust isn’t configured).

Cheat strip