What Is DHCPv4 Relay?

Routers don’t forward broadcast traffic between subnets — that’s the whole point of a router, keeping broadcast domains contained. Most of the time that’s exactly what you want. But DHCP’s initial DISCOVER message is a broadcast, sent by a client that has no IP address yet and therefore no way to address anything directly. If the DHCP server lives on a different subnet than the client — which is normal in any network bigger than a single LAN — that broadcast simply dies at the first router it hits.

This is the exact problem DHCPv4 relay solves, and it’s one of the more practical, frequently-tested configuration topics in CCNA. This guide covers why the problem happens, how relay fixes it, the full configuration and verification workflow, and the troubleshooting steps for when it doesn’t work as expected.

Why the Client Fails Without Relay

Picture a laptop booting up with no configured IP address, connected through Router0, with the actual DHCP server sitting on a completely different subnet reachable only through other routers. The sequence plays out like this:

1. The laptop broadcasts a DHCPDISCOVER message, since it has no address yet and no way to reach the server directly.
2. Router0 receives the broadcast on its local interface — but by default, routers do not forward broadcast traffic between subnets. The DISCOVER message goes nowhere.
3. With no DHCPOFFER ever arriving, the client eventually falls back to Automatic Private IP Addressing (APIPA), self-assigning an address in the 169.254.0.0/16 range so it at least has something, even though that address is only usable for communicating with other APIPA-addressed devices on the same local segment — not the rest of the network.

Running ipconfig /release followed by ipconfig /renew on the client demonstrates this cleanly: the release resets the address to 0.0.0.0, and the renew attempt sends a fresh DHCPDISCOVER that fails the same way, for the same reason — the broadcast never leaves the local subnet.

Adding a dedicated DHCP server to every single subnet would technically fix this, but it’s expensive and adds administrative overhead that scales badly as a network grows. There’s a much simpler fix.

The Fix: ip helper-address

The Cisco IOS ip helper-address command turns a router interface into a DHCPv4 relay agent. Instead of silently dropping the broadcast, the router:

1. Receives the DHCPDISCOVER broadcast on the interface.
2. Stamps its own interface address into the packet’s giaddr (gateway IP address) field — this is what lets the DHCP server later figure out which subnet the request came from, so it knows which address pool to lease from.
3. Converts the message into a unicast packet addressed directly to the configured helper address (the DHCP server’s IP).
4. Forwards the reply back to the client the same way it came in.

Configuration

Router0> enable
Router0# configure terminal
Router0(config)# interface gigabitEthernet 0/1
Router0(config-if)# ip helper-address 172.16.0.1
Router0(config-if)# exit

Apply the command on the interface facing the clients — the interface where the broadcast originates — not on the interface facing the DHCP server. The router relays the request out toward whichever interface actually routes to the helper address.

If clients on this subnet might need to reach more than one DHCP server (for redundancy, or because different servers handle different services), the interface can carry multiple helper-address lines:

Router0(config-if)# ip helper-address 172.16.0.1
Router0(config-if)# ip helper-address 172.16.0.2

Each broadcast gets relayed to every configured helper address.

Verifying the Configuration

Router0# show ip interface gigabitEthernet 0/1

This confirms the helper address is applied to the correct interface. Once relay is working, clients that previously fell back to APIPA should successfully obtain a real address from the DHCP server on the remote subnet — confirm this on the client itself with ipconfig /all (Windows) or by checking the assigned address, subnet mask, gateway, and DNS server all match what the DHCP pool is configured to hand out.

Relay vs. a Dedicated Server on Every Subnet

The article opened with the alternative: a DHCP server on every subnet instead of relaying to one central server. It’s worth being specific about the trade-off, since “more expensive and more overhead” undersells it.

	Relay (ip helper-address)	Dedicated Server per Subnet
Number of servers to manage	One (or a small redundant pair)	One per subnet
Consistency of policy (lease times, DNS, options)	Centralized — change once, applies everywhere	Must be replicated and kept in sync manually
Cost	Low — a config line per interface	Higher — hardware or VM per location, plus licensing where applicable
Failure impact	Central server outage affects every relayed subnet	A single server outage only affects its own subnet
Administrative overhead	Low	Scales up with every subnet added

The single point of failure is the real trade-off relay introduces — a redundant pair of central DHCP servers (using multiple ip helper-address lines pointing at both servers) is the standard way to address that, rather than reverting to a separate server on every subnet.

Worked Example: What Actually Changes in the Packet

It helps to see the relay’s effect on the packet itself, not just the high-level “broadcast becomes unicast” description.

Client’s original DHCPDISCOVER, as sent:

Src IP: 0.0.0.0            Src Port: 68
Dst IP: 255.255.255.255    Dst Port: 67
giaddr: 0.0.0.0            (client has no gateway info yet)

Same packet, after Router0 relays it toward the DHCP server:

Src IP: 172.16.10.1        Src Port: 67   (Router0's relaying interface)
Dst IP: 172.16.0.1         Dst Port: 67   (the configured helper address)
giaddr: 172.16.10.1        (Router0's interface address — stamped in by the relay)

Two things changed: the destination went from a broadcast to a specific unicast address, and the giaddr field — previously all zeros — now holds the relaying router’s own interface address. That second change is doing more work than it looks like. When the DHCP server replies, it reads giaddr to figure out which subnet actually needs an address, and selects a lease from the matching pool. Without a correctly stamped giaddr, a server managing pools for multiple subnets would have no reliable way to know which pool the request belongs to.

This is also why the helper address has to be configured on the interface actually facing the client’s subnet: the giaddr gets set to that interface’s address, and the DHCP pool it’s meant to match has to correspond to it. A helper address configured on the wrong interface stamps the wrong giaddr, and the client gets offered an address from the wrong subnet — or no offer at all, if no pool matches.

Scenario: Relay Across Multiple VLANs

A single router or Layer 3 switch often needs to relay for several VLANs at once, each with its own SVI. This is where ip helper-address placement most commonly goes wrong for people new to the command — it’s easy to assume one helper address on one interface covers the whole device, but it doesn’t.

Say a Layer 3 switch has three SVIs — VLAN 10, VLAN 20, and VLAN 30 — and a single central DHCP server at 172.16.0.1 handles address pools for all three:

Switch(config)# interface vlan 10
Switch(config-if)# ip helper-address 172.16.0.1
Switch(config-if)# exit
Switch(config)# interface vlan 20
Switch(config-if)# ip helper-address 172.16.0.1
Switch(config-if)# exit
Switch(config)# interface vlan 30
Switch(config-if)# ip helper-address 172.16.0.1
Switch(config-if)# exit

Each SVI needs its own ip helper-address line, even though they’re all pointing at the same server. The giaddr field gets stamped differently on each one — VLAN 10’s SVI address, VLAN 20’s SVI address, and so on — which is exactly what lets one DHCP server correctly serve three separate address pools from a single device. Forgetting the line on even one VLAN means clients on that VLAN alone fall back to APIPA, while the other two VLANs work fine — a pattern that often confuses people troubleshooting it for the first time, since “DHCP is broken” turns out to only be true for part of the network.

What Else ip helper-address Forwards

DHCP isn’t the only broadcast-based service that has this same cross-subnet problem, so ip helper-address forwards more than just DHCP traffic by default. It relays eight UDP services:

Port	Service
37	Time
49	TACACS
53	DNS
67	BOOTP/DHCP server
68	BOOTP/DHCP client
69	TFTP
137	NetBIOS Name Service
138	NetBIOS Datagram Service

If forwarding all eight isn’t desirable — for example, if NetBIOS broadcast traffic is causing problems on a remote segment — individual ports can be disabled globally with no ip forward-protocol udp <port>, without affecting the others.

Troubleshooting DHCPv4 Relay

Symptom	Likely Cause	Fix
Client still gets a 169.254.x.x (APIPA) address	ip helper-address missing or applied to the wrong interface	Confirm it’s on the client-facing interface with show ip interface
Client gets an address from the wrong pool or subnet	giaddr field not being set correctly, or DHCP pool misconfigured for that subnet	Verify the DHCP server has a pool matching the relaying interface’s subnet
Relay works for DHCP but breaks other services	All eight default UDP ports are being forwarded, including ones not wanted	Use no ip forward-protocol udp <port> to disable specific unwanted services
Client on a VLAN never gets an offer	Helper address configured on the wrong SVI, or the DHCP server subnet is unreachable from the router	Check routing to the DHCP server’s subnet independently of the DHCP configuration itself
Works for one subnet but not another on the same router	Helper address only configured on one interface	ip helper-address is per-interface — it must be applied everywhere clients need relay service

FAQs

What is DHCPv4 relay?

It’s the process by which a router (or a dedicated relay agent) forwards DHCP broadcast requests from clients to a DHCP server on a different subnet, since routers don’t forward broadcasts on their own.

How does DHCPv4 relay actually work?

The relay agent receives the client’s broadcast DHCPDISCOVER, stamps its own interface address into the packet’s giaddr field so the server knows which subnet to serve, and forwards the message as a unicast directly to the configured helper address. The server’s response is relayed back to the client the same way.

Why is DHCPv4 relay important?

It lets one centralized DHCP server support many subnets, instead of requiring a dedicated server on every single subnet — which would be expensive and harder to manage consistently as the network grows.

What are the benefits of using DHCPv4 relay?

Centralized DHCP management, lower administrative overhead, and easier scaling — adding a new subnet just means adding an ip helper-address line, not deploying another server.

How do you configure DHCPv4 relay on a Cisco router?

Apply ip helper-address <server-IP> in interface configuration mode, on the interface facing the clients. That’s the entire configuration — no separate relay profile or additional object needs to be created on Cisco IOS.

Does ip helper-address only forward DHCP traffic?

No — by default it forwards eight UDP services: DHCP/BOOTP (ports 67 and 68), DNS (53), TFTP (69), Time (37), TACACS (49), and NetBIOS Name and Datagram services (137, 138). Any of these can be disabled individually with no ip forward-protocol udp <port> if only DHCP relay is actually needed.

Can one interface relay to more than one DHCP server?

Yes. Configuring multiple ip helper-address lines on the same interface relays each broadcast to every listed server — useful for redundancy or when different servers handle different services. If the primary server doesn’t respond, the client’s own DHCP retry logic will pick up an offer from whichever configured server does.