DHCP Relay Agent — ip helper-address

A DHCP client discovers its server by broadcasting a DHCP Discover packet — a broadcast that every device on the local segment receives. Routers, by design, do not forward broadcasts between subnets. In a network with a centralised DHCP server serving multiple subnets, this creates a problem: hosts on any subnet other than the server's own cannot reach the server at all. For DHCP fundamentals see DHCP and How DHCP Works.

The ip helper-address command transforms a Cisco router into a DHCP relay agent. When a client broadcast arrives on an interface with a helper-address configured, the router intercepts it, rewrites it as a unicast packet addressed to the configured server IP, and forwards it across the routed network. From the DHCP server's perspective, the relay agent's interface IP identifies which subnet pool to use — enabling one server to serve dozens of subnets simultaneously.

This lab builds directly on DHCP Server Configuration — the DHCP server pools configured there are the server-side prerequisite for this lab. Review OSPF Single-Area Configuration or Static Route Configuration to understand the routed path the relayed packets travel. For VLAN segmentation that creates the separate subnets requiring relay see VLANs and VLAN Creation & Management. For inter-VLAN routing at the distribution layer see Inter-VLAN Routing (Router-on-a-Stick) and Inter-VLAN Routing (Layer 3 Switch).

1. Why Broadcasts Don't Cross Routers — and How Relay Fixes It

The Broadcast Boundary Problem

DHCP clients have no IP address when they start — they cannot send a unicast packet. Every DHCP Discover is a Layer 3 broadcast (255.255.255.255) with a Layer 2 broadcast (FF:FF:FF:FF:FF:FF) MAC. Routers drop these broadcasts at their interface — they never cross to another subnet. Without a relay agent, every subnet needs its own local DHCP server:

  Without ip helper-address:

  [PC1 — 192.168.10.x]──── Router ────[DHCP Server — 10.0.12.1]
       DHCP Discover (broadcast) ──►  X  DROPPED at Router
       PC1 cannot reach the DHCP server

  With ip helper-address 10.0.12.1 on Router's Gi0/0:

  [PC1 — 192.168.10.x]──── Router ────[DHCP Server — 10.0.12.1]
       DHCP Discover (broadcast) ──►  Router intercepts broadcast
                                       Rewrites as UNICAST to 10.0.12.1
                                       Adds giaddr = 192.168.10.1
                                  ──►  DHCP Server receives unicast Discover
                                       Selects pool matching 192.168.10.0/24
                                       Sends Offer back to Router
                                  ──►  Router forwards Offer to PC1
       PC1 receives DHCP address!

What ip helper-address Does — Step by Step

Step	Action by Relay Router	Technical Detail
1	Receives DHCP Discover broadcast on the LAN interface	Broadcast arrives on the interface where `ip helper-address` is configured
2	Records the client's MAC address and incoming interface	Used to forward the server's reply back to the correct client
3	Sets the giaddr field to its own interface IP on the client's subnet	giaddr = gateway IP address. The DHCP server uses this to select the correct pool
4	Changes destination from broadcast (255.255.255.255) to unicast (server IP)	The relayed packet is now a routable unicast UDP packet to port 67
5	Forwards the unicast Discover to the DHCP server	Normal IP routing applies — the server IP must be reachable from the relay router
6	Receives the server's Offer/Acknowledge (unicast back to relay)	Server unicasts reply to giaddr (relay router), not the client
7	Forwards the Offer/Acknowledge to the client as broadcast or unicast	Client may receive as broadcast since it still has no IP for unicast delivery

giaddr — The Key to Pool Selection

The giaddr (Gateway IP Address) field is the most important element of DHCP relay operation. The relay agent fills this field with its own IP address on the client-facing interface before forwarding the Discover to the server. The DHCP server inspects the giaddr and selects the pool whose network statement contains that IP:

Relay Interface IP (giaddr)	DHCP Pool Matched	Address Range Offered
192.168.10.1	STAFF-VLAN10 (network 192.168.10.0/24)	192.168.10.21 – 192.168.10.254
192.168.20.1	GUEST-VLAN20 (network 192.168.20.0/24)	192.168.20.11 – 192.168.20.254
192.168.30.1	REMOTE-VLAN30 (network 192.168.30.0/24)	192.168.30.11 – 192.168.30.254

The relay router does not need to be the DHCP server. Its only job is to intercept broadcasts, add the giaddr, and forward them as unicast. The DHCP server can be anywhere in the routed network as long as there is a routed path between the relay router and the server.

Additional Protocols Forwarded by ip helper-address

By default, ip helper-address forwards broadcasts for eight UDP protocols — not just DHCP:

Protocol	UDP Port	Notes
DHCP / BOOTP	67, 68	The primary use case for ip helper-address
TFTP	69	Used for booting diskless workstations
DNS	53	Forwarded if DNS uses broadcasts (uncommon)
NetBIOS Name Service	137	Windows NetBIOS name resolution
NetBIOS Datagram Service	138	Windows NetBIOS datagrams
Time Protocol	37	Legacy time synchronisation
IEN-116 Name Service	42	Legacy name service
TAC News	49	Legacy protocol

To restrict forwarding to DHCP only (recommended for security), disable the other protocols with: no ip forward-protocol udp 69, no ip forward-protocol udp 53, etc. Leave ports 67 and 68 enabled for DHCP to function. For additional Layer 2 DHCP security see DHCP Snooping and DHCP Snooping & Dynamic ARP Inspection.

2. Lab Topology & Scenario

One centralised DHCP server (on NetsTuts_R1, also acting as the DHCP server itself) serves three separate VLANs across two distribution routers (NetsTuts_R2 and NetsTuts_R3). R2 and R3 each act as relay agents for their directly connected client subnets — forwarding DHCP requests back to R1.

                    ┌──────────────────────────────┐
                    │        NetsTuts_R1            │
                    │   DHCP Server (3 pools)       │
                    │   Loopback0: 1.1.1.1/32       │
                    │   Gi0/1: 10.0.12.1/30         │
                    │   Gi0/2: 10.0.13.1/30         │
                    └──────────────────────────────┘
                         |                   |
                   10.0.12.0/30        10.0.13.0/30
                         |                   |
                   10.0.12.2/30        10.0.13.2/30
              ┌──────────────────┐   ┌──────────────────┐
              │  NetsTuts_R2     │   │  NetsTuts_R3     │
              │  Relay Agent     │   │  Relay Agent     │
              │  Gi0/0:10.0.12.2 │   │  Gi0/0:10.0.13.2 │
              │  Gi0/1:10.0.23.1 │   │  Gi0/1:10.0.23.2 │
              └──────────────────┘   └──────────────────┘
              Gi0/2      Gi0/3         Gi0/2       Gi0/3
         192.168.10.1  192.168.20.1  192.168.30.1 192.168.40.1
              |              |            |             |
        VLAN10/24      VLAN20/24     VLAN30/24     VLAN40/24
        [PC1][PC2]    [Laptop1]     [PC3][PC4]    [Phone1]
        Staff          Guest         Branch        Voice

  DHCP Server: R1 (reachable via OSPF or static routes)
  Relay on R2 interfaces: Gi0/2 and Gi0/3
  Relay on R3 interfaces: Gi0/2 and Gi0/3

DHCP Pool	Network	Default Gateway	Relay Interface	Helper-Address
STAFF-VLAN10	192.168.10.0 /24	192.168.10.1	R2 Gi0/2	10.0.12.1 (R1)
GUEST-VLAN20	192.168.20.0 /24	192.168.20.1	R2 Gi0/3	10.0.12.1 (R1)
BRANCH-VLAN30	192.168.30.0 /24	192.168.30.1	R3 Gi0/2	10.0.13.1 (R1)
VOICE-VLAN40	192.168.40.0 /24	192.168.40.1	R3 Gi0/3	10.0.13.1 (R1)

3. Step 1 — Configure DHCP Server Pools on R1

Four pools are required — one per VLAN. Exclusions are configured first. R1's loopback (1.1.1.1) is used as the ip helper-address target on R2 and R3 — a loopback is preferred over a physical interface IP because loopbacks never go down and provide a stable, always-reachable destination for relayed DHCP packets:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Exclude static/reserved addresses from all pools ─────
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.10.1 192.168.10.20
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.20.1 192.168.20.10
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.30.1 192.168.30.10
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.40.1 192.168.40.10

! ── Pool for Staff VLAN 10 ───────────────────────────────
NetsTuts_R1(config)#ip dhcp pool STAFF-VLAN10
NetsTuts_R1(dhcp-config)#network 192.168.10.0 255.255.255.0
NetsTuts_R1(dhcp-config)#default-router 192.168.10.1
NetsTuts_R1(dhcp-config)#dns-server 8.8.8.8 8.8.4.4
NetsTuts_R1(dhcp-config)#domain-name netstuts.local
NetsTuts_R1(dhcp-config)#lease 7
NetsTuts_R1(dhcp-config)#exit

! ── Pool for Guest VLAN 20 ───────────────────────────────
NetsTuts_R1(config)#ip dhcp pool GUEST-VLAN20
NetsTuts_R1(dhcp-config)#network 192.168.20.0 255.255.255.0
NetsTuts_R1(dhcp-config)#default-router 192.168.20.1
NetsTuts_R1(dhcp-config)#dns-server 8.8.8.8 8.8.4.4
NetsTuts_R1(dhcp-config)#lease 0 4
NetsTuts_R1(dhcp-config)#exit

! ── Pool for Branch VLAN 30 ──────────────────────────────
NetsTuts_R1(config)#ip dhcp pool BRANCH-VLAN30
NetsTuts_R1(dhcp-config)#network 192.168.30.0 255.255.255.0
NetsTuts_R1(dhcp-config)#default-router 192.168.30.1
NetsTuts_R1(dhcp-config)#dns-server 8.8.8.8 8.8.4.4
NetsTuts_R1(dhcp-config)#domain-name netstuts.local
NetsTuts_R1(dhcp-config)#lease 1
NetsTuts_R1(dhcp-config)#exit

! ── Pool for Voice VLAN 40 ───────────────────────────────
NetsTuts_R1(config)#ip dhcp pool VOICE-VLAN40
NetsTuts_R1(dhcp-config)#network 192.168.40.0 255.255.255.0
NetsTuts_R1(dhcp-config)#default-router 192.168.40.1
NetsTuts_R1(dhcp-config)#dns-server 8.8.8.8
NetsTuts_R1(dhcp-config)#option 150 ip 192.168.40.5
NetsTuts_R1(dhcp-config)#lease 1
NetsTuts_R1(dhcp-config)#exit

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

The VOICE-VLAN40 pool includes option 150 ip 192.168.40.5 — DHCP Option 150 provides the IP address of the TFTP server (usually the call manager) to Cisco IP phones during boot. Phones use this to download their firmware and configuration. This is a standard addition to any voice VLAN DHCP pool. For voice VLAN configuration on the access switch see Voice VLAN and Voice VLAN Configuration. For DNS configuration on client devices see How DNS Works.

Why use R1's Loopback as the helper target: If ip helper-address points to R1's physical interface IP (e.g., 10.0.12.1) and that interface goes down, relay fails for the subnets behind R2 — even if R1 is reachable via an alternate path. Using a loopback IP (1.1.1.1) as the helper target means the relay uses any available path to reach R1, making DHCP relay resilient to single interface failures.

4. Step 2 — Configure Relay Agent on NetsTuts_R2

ip helper-address is configured on each client-facing interface of R2 — one per VLAN/subnet. Both interfaces point to R1's loopback (1.1.1.1) as the DHCP server. The key rule: configure the helper-address on the interface where client broadcasts arrive, never on the uplink toward the server.

NetsTuts_R2>en
NetsTuts_R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Relay for VLAN 10 clients (Staff) ────────────────────
NetsTuts_R2(config)#interface GigabitEthernet0/2
NetsTuts_R2(config-if)#description Staff-VLAN10-192.168.10.0/24
NetsTuts_R2(config-if)#ip address 192.168.10.1 255.255.255.0
NetsTuts_R2(config-if)#ip helper-address 1.1.1.1
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#exit

! ── Relay for VLAN 20 clients (Guest) ────────────────────
NetsTuts_R2(config)#interface GigabitEthernet0/3
NetsTuts_R2(config-if)#description Guest-VLAN20-192.168.20.0/24
NetsTuts_R2(config-if)#ip address 192.168.20.1 255.255.255.0
NetsTuts_R2(config-if)#ip helper-address 1.1.1.1
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#end
NetsTuts_R2#wr
Building configuration...
[OK]
NetsTuts_R2#

Both interfaces on R2 use the same helper-address (1.1.1.1 — R1's loopback) but each carries a different giaddr when relaying DHCP. Gi0/2 sends giaddr 192.168.10.1 and Gi0/3 sends giaddr 192.168.20.1 — R1 uses these different giaddr values to select STAFF-VLAN10 and GUEST-VLAN20 pools respectively. One server, two pools, two relay interfaces, all working simultaneously.

5. Step 3 — Configure Relay Agent on NetsTuts_R3

NetsTuts_R3>en
NetsTuts_R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Relay for VLAN 30 clients (Branch) ───────────────────
NetsTuts_R3(config)#interface GigabitEthernet0/2
NetsTuts_R3(config-if)#description Branch-VLAN30-192.168.30.0/24
NetsTuts_R3(config-if)#ip address 192.168.30.1 255.255.255.0
NetsTuts_R3(config-if)#ip helper-address 1.1.1.1
NetsTuts_R3(config-if)#no shutdown
NetsTuts_R3(config-if)#exit

! ── Relay for VLAN 40 clients (Voice) ────────────────────
NetsTuts_R3(config)#interface GigabitEthernet0/3
NetsTuts_R3(config-if)#description Voice-VLAN40-192.168.40.0/24
NetsTuts_R3(config-if)#ip address 192.168.40.1 255.255.255.0
NetsTuts_R3(config-if)#ip helper-address 1.1.1.1
NetsTuts_R3(config-if)#no shutdown
NetsTuts_R3(config-if)#exit

NetsTuts_R3(config)#end
NetsTuts_R3#wr
Building configuration...
[OK]
NetsTuts_R3#

6. Multiple Helper Addresses — Redundant DHCP Servers

In production networks, a single DHCP server is a single point of failure. Cisco IOS supports multiple ip helper-address entries on the same interface — the relay forwards every DHCP Discover to all configured servers simultaneously. The client receives offers from whichever server responds first:

! ── Relay to two DHCP servers — primary and secondary ────
NetsTuts_R2(config)#interface GigabitEthernet0/2
NetsTuts_R2(config-if)#ip helper-address 1.1.1.1
NetsTuts_R2(config-if)#ip helper-address 2.2.2.2
NetsTuts_R2(config-if)#exit

Both 1.1.1.1 (primary DHCP server on R1) and 2.2.2.2 (secondary DHCP server) receive every relayed Discover from this interface. Both send Offers to the client — the client accepts the first one that arrives (typically whichever is closer/faster to respond) and sends a Request naming the chosen server. The unchosen server sees the Request, recognises its Offer was not selected, and returns the address to its pool.

Redundant Server Design Considerations

Consideration	Details
Non-overlapping address ranges	Each DHCP server must serve a different portion of the subnet — e.g., primary handles .21–.150 and secondary handles .151–.253 — to avoid both servers offering the same address
80/20 rule	A common design: primary server holds 80% of the pool, secondary holds 20%. Most clients use the primary; secondary covers primary failure
Same pool parameters	Both servers must have matching default-router, dns-server, and domain-name — clients receive identical configuration regardless of which server responds

7. Verification

show ip dhcp binding — on R1 (Server)

NetsTuts_R1#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address       Client-ID/              Lease expiration        Type       State
                 Hardware address
192.168.10.21    0100.5056.AB.11.22      Mar 12 2026 09:00 AM    Automatic  Active
192.168.10.22    0100.5056.AB.33.44      Mar 12 2026 09:02 AM    Automatic  Active
192.168.20.11    0100.AABB.CC.DD.EE      Mar 05 2026 02:00 PM    Automatic  Active
192.168.30.11    0100.1234.56.78.90      Mar 06 2026 09:10 AM    Automatic  Active
192.168.40.11    0100.FEDC.BA.98.76      Mar 06 2026 09:15 AM    Automatic  Active

R1 shows bindings for all four subnets — even though none of those clients are directly connected to R1. Clients on 192.168.20.x, .30.x, and .40.x reached R1 via relay. R1 has no idea whether the client used a relay agent or connected directly — the DHCP process is identical from R1's perspective.

show running-config interface — Verify Relay on R2

NetsTuts_R2#show running-config interface GigabitEthernet0/2
Building configuration...

Current configuration : 128 bytes
!
interface GigabitEthernet0/2
 description Staff-VLAN10-192.168.10.0/24
 ip address 192.168.10.1 255.255.255.0
 ip helper-address 1.1.1.1
 no shutdown
end

NetsTuts_R2#show running-config interface GigabitEthernet0/3
Building configuration...

Current configuration : 128 bytes
!
interface GigabitEthernet0/3
 description Guest-VLAN20-192.168.20.0/24
 ip address 192.168.20.1 255.255.255.0
 ip helper-address 1.1.1.1
 no shutdown
end

Both client-facing interfaces on R2 show ip helper-address 1.1.1.1. Verify the helper is on the correct (client-facing) interface — a helper on the wrong interface is the single most common DHCP relay misconfiguration. For full interface status see show ip interface brief and show running-config.

debug ip dhcp server packet — Live Relay Trace on R1

NetsTuts_R1#debug ip dhcp server packet
DHCP server packet debugging is on.
NetsTuts_R1#
DHCPD: DHCPDISCOVER received from client 0100.5056.AB.11.22
       through relay 192.168.10.1 on GigabitEthernet0/1
DHCPD: Allocating address 192.168.10.21 to client
DHCPD: DHCPOFFER sent to 192.168.10.1 for client 0100.5056.AB.11.22
DHCPD: DHCPREQUEST received from client 0100.5056.AB.11.22
DHCPD: DHCPACK sent to 192.168.10.1 for client 0100.5056.AB.11.22
       IP address 192.168.10.21

The debug output on R1 shows: "received from client ... through relay 192.168.10.1" — R1 can see that this DHCP transaction was relayed (not direct). The relay agent's IP (192.168.10.1 — R2's Gi0/2) appears in the debug. R1 sent the Offer and ACK back to the relay agent (192.168.10.1), not directly to the client. Always disable debugging after use:

no debug ip dhcp server
    packet

or undebug all.

show ip dhcp server statistics — Verify Relay Traffic

NetsTuts_R1#show ip dhcp server statistics
Memory usage         : 24311
Address pools        : 4
Database agents      : 0
Automatic bindings   : 5
Manual bindings      : 0
Expired bindings     : 0
Malformed messages   : 0

Message              Received
DHCPDISCOVER         18
DHCPREQUEST          16
DHCPRELEASE          3

Message              Sent
DHCPOFFER            18
DHCPACK              16
DHCPNAK              0

DHCPDISCOVER (18) matches DHCPOFFER (18) — every Discover received an Offer. DHCPREQUEST (16) matches DHCPACK (16) — every Request completed successfully. DHCPNAK = 0 — no refused requests. DHCPRELEASE (3) = three clients cleanly released their addresses. These counters include both direct and relayed clients — R1 cannot distinguish between them in the statistics.

Ping the DHCP Server from Relay Router — Connectivity Check

! ── Verify R2 can reach R1's loopback (the helper target) ─
NetsTuts_R2#ping 1.1.1.1 source GigabitEthernet0/2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 ms
NetsTuts_R2#

This is the most important relay prerequisite check. The relay router must be able to reach the helper-address (1.1.1.1) from the client-facing interface. Using source GigabitEthernet0/2 (192.168.10.1) as the source simulates the exact path the relayed DHCP unicast will take — confirming routing and ACLs permit this traffic before testing DHCP.

Verification Command Summary

Command	What It Shows	Run On
`show running-config interface [int]`	Confirms `ip helper-address` is on the correct client-facing interface	Relay router (R2, R3)
`show ip dhcp binding`	All active leases including relay clients — verify remote subnet addresses appear	DHCP server (R1)
`show ip dhcp pool`	Pool utilisation per subnet — confirm leases are being issued from each pool	DHCP server (R1)
`ping [helper-address] source [relay-int]`	Verifies routed connectivity from relay interface to DHCP server — prerequisite for relay	Relay router (R2, R3)
`debug ip dhcp server packet`	Live DORA trace — shows "through relay [IP]" confirming relay operation	DHCP server (R1) — disable after use
`show logging`	DHCP event log — relay events and any DHCP assignment failures	All routers

8. Troubleshooting DHCP Relay Issues

Problem	Symptom	Cause	Fix
Relay clients get APIPA — direct clients work	Hosts on remote subnets show 169.254.x.x but hosts on the server's local subnet work fine	`ip helper-address` missing or on wrong interface. Or the helper-address IP is unreachable from the relay router	Verify: `show running-config interface [LAN-int]` — confirm helper is present and on the client-facing interface. Ping the helper-address from the relay interface: `ping [helper] source [relay-int]`
Relay clients get addresses from wrong pool	Hosts on 192.168.30.0/24 receive addresses in 192.168.10.x range instead	giaddr mismatch — the helper-address is configured on the wrong interface (not the one with the correct subnet IP), so the wrong giaddr is sent to the server	Check which interface has the helper — its IP address becomes the giaddr. The interface IP must match the pool's network statement on the server. Move the helper to the correct interface.
No DHCP binding appears on server for relay clients	`show ip dhcp binding` shows no entries for remote subnets despite relay being configured	Routing issue — relayed DHCP unicast (UDP/67) cannot reach the server, or return path is missing. Also check for ACLs blocking UDP port 67/68 between relay and server.	Run `debug ip dhcp server packet` on R1 — if no Discovers appear, the relay packet is not arriving. Check routing with `ping [R1-loopback] source [relay-int]`. Review ACLs with `show ip access-lists` — see ACL Overview and Extended ACL Configuration for ACL troubleshooting.
DHCP works then breaks after network change	DHCP relay was working but stops after a routing change or interface failure	The helper-address pointed to a physical interface IP on R1 — that interface went down. Relayed unicasts now have no route to the old physical IP.	Change helper-address to point to R1's loopback interface instead of a physical IP. Loopbacks are always up as long as the router is running — making relay resilient to individual interface failures.
Both DHCP servers responding — clients get inconsistent config	Some hosts get correct DNS/gateway, others get wrong values — two helper-addresses configured	Two DHCP servers have overlapping pools or inconsistent pool parameters (different default-router or dns-server values)	Ensure both servers use non-overlapping address ranges and identical DHCP options (default-router, dns-server, domain-name). The client receives options from whichever server's ACK it accepts.
Voice phones fail to boot — Option 150 missing	IP phones receive an IP address but cannot download config — "No Service" on phone display	DHCP pool for the Voice VLAN is missing `option 150` (TFTP server address for Cisco phones)	Add `option 150 ip [call-manager-IP]` to the voice VLAN pool on R1. Phones use this to locate the TFTP server for firmware and config download.

Key Points & Exam Tips

Routers drop DHCP broadcasts by default — ip helper-address converts the client's broadcast Discover into a unicast packet addressed to the configured DHCP server IP and forwards it across the routed network.
ip helper-address must be configured on the client-facing interface — the interface where DHCP Discover broadcasts arrive. Configuring it on the uplink (toward the server) has no effect on client broadcasts.
The relay agent sets the giaddr (Gateway IP Address) field to its own IP on the client-facing interface. The DHCP server uses the giaddr to determine which pool to select — the pool whose network statement contains the giaddr.
Using a loopback IP as the helper-address target is best practice — loopbacks never go down, making relay resilient to physical interface failures on the server router.
Multiple ip helper-address entries on the same interface relay to multiple servers simultaneously — all servers receive every Discover. Use non-overlapping address ranges to avoid duplicate offers for the same address.
By default, ip helper-address forwards 8 UDP broadcast protocols including DHCP (67/68), TFTP (69), DNS (53), and NetBIOS (137/138). Restrict to DHCP only with no ip forward-protocol udp [port] for security.
The relay router needs a routed path to reach the DHCP server. If routing or ACLs block UDP port 67/68 between the relay router and server, DHCP relay silently fails.
Verify relay connectivity with ping [helper-address] source [relay-interface] before testing DHCP — this confirms the exact path the relayed unicast will use.
debug ip dhcp server packet on the DHCP server shows "through relay [IP]" for relayed transactions — confirming the relay is working and identifying which relay agent forwarded the request.
On the CCNA exam: know why DHCP broadcasts don't cross routers, where to place ip helper-address, what giaddr is used for, and that multiple helper-addresses provide DHCP server redundancy.

Next Steps: With DHCP relay operational across all subnets, verify hosts receive the correct gateway by combining this with HSRP — First Hop Redundancy and HSRP Overview to provide gateway redundancy. For securing the DHCP infrastructure against rogue servers see DHCP Snooping and DHCP Snooping & Dynamic ARP Inspection. For troubleshooting DHCP from the client side see Troubleshooting DHCP Clients. For securing the management plane of the relay routers, complete SSH Configuration and AAA Authentication Methods. For saving the relay configuration see Saving & Managing Cisco Configurations.

TEST WHAT YOU LEARNED

1. A network engineer configures `ip helper-address 10.0.12.1` on R2's Gi0/0 interface (the uplink to R1) instead of Gi0/2 (the LAN interface facing clients). What happens when PC1 on the 192.168.10.0/24 LAN sends a DHCP Discover?

A. DHCP works normally — helper-address forwards broadcasts regardless of which interface it is placed on B. DHCP partially works — R2 forwards the broadcast but uses the wrong giaddr C. PC1's DHCP Discover arrives on Gi0/2 where no helper-address is configured — R2 drops the broadcast. The Discover never reaches R1 and PC1 receives an APIPA address D. R2 forwards the broadcast on Gi0/0 toward R1 but R1 drops it because it expects unicast

Correct answer is C. The ip helper-address command only activates when a DHCP broadcast is received on the interface where it is configured. PC1's DHCP Discover arrives on R2's Gi0/2 (the LAN interface). Since helper-address is on Gi0/0 (the uplink), not Gi0/2, R2 has no relay instruction for broadcasts arriving on Gi0/2 and drops them. PC1 gets no DHCP Offer and falls back to APIPA. The fix is to move ip helper-address 10.0.12.1 to Gi0/2 — the interface where client broadcasts actually arrive.

2. R2 has `ip helper-address 1.1.1.1` on both Gi0/2 (192.168.10.1) and Gi0/3 (192.168.20.1). Both interfaces point to the same DHCP server (R1 at 1.1.1.1). How does R1 know which pool to use for each client?

A. R1 reads the giaddr field set by R2 — Gi0/2 sets giaddr to 192.168.10.1 and Gi0/3 sets giaddr to 192.168.20.1. R1 matches each giaddr to the pool whose network statement contains that IP B. R1 uses the client's source MAC address to determine the correct pool C. R1 assigns from both pools simultaneously and the client picks the preferred address D. R1 uses the incoming interface on which it receives the relayed unicast to identify the pool

Correct answer is A. The giaddr (Gateway IP Address) field is the mechanism that allows one DHCP server to serve multiple subnets via relay. When R2 relays a Discover from Gi0/2, it sets giaddr to 192.168.10.1 (the IP of Gi0/2). When relaying from Gi0/3, giaddr becomes 192.168.20.1. R1 receives both as unicast packets from the same relay router but with different giaddr values. R1 checks which pool network contains each giaddr — STAFF-VLAN10 contains .10.1 and GUEST-VLAN20 contains .20.1 — and assigns from the correct pool. This is why the relay interface IP must match the pool's network statement.

3. Why is it best practice to configure `ip helper-address` pointing to a loopback IP on the DHCP server rather than a physical interface IP?

A. Loopback addresses have lower latency — DHCP relay responds faster B. Physical interface IPs change when cables are reconnected — loopbacks are more stable in addressing C. DHCP server processes only listen on loopback interfaces by default in Cisco IOS D. Loopback interfaces never go down as long as the router is running — if the helper-address points to a physical interface IP and that interface fails, relay fails even if alternate paths to the server exist. A loopback IP allows routing to use any available path

Correct answer is D. When ip helper-address points to a physical interface IP (e.g., 10.0.12.1), the relayed DHCP unicast has that specific IP as its destination. If the interface with 10.0.12.1 goes down (cable failure, interface flap), that destination becomes unreachable — relay fails even if the DHCP server is reachable via a redundant path. Loopback interfaces are always up while the router is powered on. Pointing the helper to a loopback IP (1.1.1.1) means IOS can route the DHCP unicast via any available path — making relay resilient to individual physical link failures.

4. `debug ip dhcp server packet` on R1 shows: "DHCPDISCOVER received from client ... through relay 192.168.30.1 on GigabitEthernet0/2." What does "through relay 192.168.30.1" tell you?

B. The DHCP Discover was relayed — the giaddr field contains 192.168.30.1, meaning the relay agent's client-facing interface IP is 192.168.30.1. R1 will use the pool matching 192.168.30.0/24 and send the reply back to 192.168.30.1 A. The client has already been partially configured and has IP 192.168.30.1 as its current address C. The DHCP Discover arrived on R1's Gi0/2 interface which has IP 192.168.30.1 D. The relay agent at 192.168.30.1 is forwarding the request using broadcast — the "through relay" wording indicates Layer 2 broadcast forwarding

Correct answer is B. In the debug output, "through relay [IP]" always refers to the giaddr field in the DHCP packet — the relay agent's interface IP on the client-facing side. This tells you: (1) the request was relayed (not direct), (2) the relay agent's LAN interface is 192.168.30.1, and (3) R1 will select the pool whose network contains 192.168.30.1 (the BRANCH-VLAN30 pool). R1 sends its Offer and Acknowledge as a unicast back to 192.168.30.1, not to the client's IP (which is still 0.0.0.0 at this stage).

5. Two helper-addresses are configured on R2's Gi0/2: `ip helper-address 1.1.1.1` and `ip helper-address 2.2.2.2`. Both servers have pools for 192.168.10.0/24 — Server 1 offers .21–.150 and Server 2 offers .151–.253. PC1 receives an Offer from both servers. What happens next?

A. PC1 accepts both offers and configures two IP addresses on the same interface B. The two servers detect the conflict and negotiate — the one with higher priority wins C. PC1 accepts the first Offer and ignores the second. Both servers permanently remove the offered addresses from their pools D. PC1 accepts the first Offer received and sends a DHCP Request (broadcast) naming the chosen server. The unchosen server receives the Request, sees its offer was declined, and returns the offered address to its available pool

Correct answer is D. The DHCP Request sent by PC1 is a broadcast — all DHCP servers on the network see it. The Request includes the Server Identifier option identifying which server was chosen. The unchosen server reads the Request, sees its own IP was not in the Server Identifier, and knows its Offer was declined. It returns the tentatively offered address to its available pool. This is the standard DHCP behaviour and why non-overlapping address ranges are critical — if both servers could offer the same address, the unchosen server would return an address already assigned by the chosen server, potentially offering it again to another client.

6. By default, `ip helper-address` forwards broadcasts for eight UDP protocols, not just DHCP. Why is it recommended to disable the non-DHCP protocols in a production network?

A. Unnecessary protocol forwarding increases router CPU load and can allow unintended traffic (DNS broadcasts, NetBIOS) to traverse routed boundaries — potentially reaching servers that should not be reachable from that subnet. Disabling unused protocols reduces attack surface and bandwidth consumption B. The extra protocols conflict with OSPF Hello packets on the same interface C. Forwarding multiple protocols causes DHCP to use TCP instead of UDP, increasing overhead D. The non-DHCP protocols prevent the giaddr from being set correctly in relayed packets

Correct answer is A. The default behaviour of ip helper-address forwards 8 UDP broadcast protocols. In most modern networks, only DHCP (ports 67/68) needs to cross router boundaries — TFTP, NetBIOS name service, and the others are either unused or should remain local. Leaving them enabled means R2 forwards NetBIOS broadcasts from the Staff VLAN to the DHCP server subnet, which could expose internal Windows naming traffic across security boundaries. Use no ip forward-protocol udp 69 (TFTP), no ip forward-protocol udp 137 (NetBIOS), etc. to restrict forwarding to DHCP only.

7. A Cisco IP phone on VLAN 40 receives an IP address from DHCP but shows "No Service" and cannot register with the call manager. The DHCP pool for VLAN 40 has network, default-router, and dns-server configured. What is missing?

A. The lease time is too short — phones need at least a 7-day lease B. The phone needs a static binding — Cisco phones do not support dynamic DHCP C. option 150 ip [call-manager-IP] is missing — Cisco IP phones require DHCP Option 150 to locate the TFTP server (call manager) for downloading firmware and configuration. Without it, the phone cannot find its configuration file and shows "No Service" D. The phone needs DHCP Option 43 instead of Option 150 — Option 150 is for Cisco switches only

Correct answer is C. Cisco IP phones use DHCP Option 150 to obtain the IP address of the TFTP server, which hosts their firmware images and configuration files. When a phone boots and receives a DHCP lease without Option 150, it has no way to locate the call manager's TFTP service — it cannot download its configuration and displays "No Service." The fix is to add option 150 ip [call-manager-IP] to the VOICE-VLAN pool on the DHCP server. Standard DHCP options (default-router, DNS) are not sufficient for VoIP phone provisioning without this option.

8. R2 is the relay agent and R1 is the DHCP server. A new ACL is applied on R1's Gi0/1 interface (facing R2) that blocks all UDP traffic. DHCP stops working for relay clients. Why does this break relay but not direct clients on R1's own subnet?

A. Direct clients use TCP for DHCP while relay clients use UDP — the ACL only blocks UDP B. Relayed DHCP travels as unicast UDP port 67 from R2 to R1 across the routed network — the ACL on Gi0/1 blocks this inbound UDP. Direct clients on R1's own subnet send broadcasts directly to R1's DHCP process which does not traverse Gi0/1, so they are unaffected C. The ACL blocks OSPF Hellos — routing between R1 and R2 fails, preventing relay D. Direct clients bypass the DHCP server entirely and use ARP for address assignment

Correct answer is B. After R2 converts the client's broadcast into a unicast, the relayed DHCP Discover travels across the routed network as a standard UDP packet (source port 67/68, destination port 67) addressed to the DHCP server's IP. This packet enters R1 via Gi0/1 — the interface where the ACL is applied. The ACL blocks all UDP, which includes the relayed DHCP unicast. Direct clients on R1's subnet (e.g., connected to R1's Gi0/0) send broadcasts that arrive on a different interface — they never pass through Gi0/1 and are unaffected by that ACL.

9. Which single command on the DHCP server confirms that relayed DHCP transactions are arriving, shows which relay agent forwarded each request, and displays the full DORA exchange in real time?

A. show ip dhcp binding B. show ip dhcp server statistics C. show ip dhcp pool D. debug ip dhcp server packet — shows live DORA messages with "through relay [IP]" indicating the relay agent, the client MAC, the allocated address, and each step of the exchange as it happens

Correct answer is D. debug ip dhcp server packet is the only command that shows all four requirements simultaneously: relay transactions (via the "through relay" text), the relay agent IP, the client MAC, and the real-time DORA sequence (DHCPDISCOVER received, DHCPOFFER sent, DHCPREQUEST received, DHCPACK sent). show ip dhcp binding shows completed leases but no relay information. show ip dhcp server statistics shows message counts but not per-client detail or relay identification. Always disable debug after use: undebug all.

10. A new VLAN 50 (192.168.50.0/24) is added to R2's Gi0/4 interface (192.168.50.1). Hosts on VLAN 50 get APIPA. R1 already has a pool for 192.168.50.0/24 with correct parameters. `ip helper-address 1.1.1.1` is confirmed on Gi0/4. The engineer pings 1.1.1.1 from R2 and it succeeds. What is the remaining likely cause?

A. The DHCP pool needs to be reloaded — new pools require a service restart B. The helper-address needs to be removed and re-added to take effect for the new interface C. The exclusion range on R1 covers the entire 192.168.50.0/24 pool — ip dhcp excluded-address 192.168.50.1 192.168.50.254 was configured too broadly, leaving no addresses available for dynamic assignment D. R2 needs OSPF reconfigured to advertise the new VLAN 50 subnet before DHCP relay can work

Correct answer is C. The relay is confirmed working (helper-address present on correct interface, server reachable via ping). The pool exists on R1. But hosts still get APIPA — which means R1 is receiving the DHCP Discover (relay is working) but cannot offer an address. The most common cause when relay and routing are confirmed healthy is an over-broad excluded-address range that consumes all available addresses in the pool. Check show ip dhcp pool on R1 — if leased + excluded = total addresses, there are no free addresses. Correct the exclusion range to only exclude the needed static addresses (e.g., .1–.10).

Back to Home