DHCP server and relay on IOS

A real-life situation

HQ is growing. Today 40 laptops on VLAN 10 need addresses, and typing them in by hand is not an option. Later, a central server (SRV1) at the server site should hand out addresses for every branch. You need R1 to do two jobs on Cisco IOS: first act as the DHCP server itself, then pass requests on to SRV1 as a relay agent. R1's internet link also gets its own address from the ISP by DHCP.

How DHCP works (the DORA exchange, leases, renewal) is covered in DHCP, which ends with a short Cisco lab. This lesson is the full IOS treatment.

What a Cisco router can do with DHCP

Why it works that way

A new client has no address and no idea where the server is, so it sends to the broadcast address 255.255.255.255. Routers never forward that broadcast to another subnet. So either the server must be on the same subnet as the client, or the router on that subnet must step in. That is all a relay agent is: the gateway catches the broadcast and sends it on, as a normal unicast packet, to a server it knows about.

The server also needs to know which subnet the client is on, to choose the right pool. When the router itself is the server, it uses the subnet of the interface the Discover arrived on. When it relays, it writes that interface's address into the giaddr (gateway IP address) field, and the server matches it against its pools.

How it works step by step (relay)

How to configure it on Cisco IOS

⚠️ Based on Cisco IOS / IOS XE documentation, not run on a lab device. Interface names vary by platform. The lab assumes routing between all subnets already works.

1. R1 as the DHCP server

Before it offers an address, the router pings it (two pings by default). If something answers, it records a conflict and skips that address. The DHCP service is on by default; if someone disabled it, service dhcp turns it back on.

2. R1 as a relay to SRV1

Now the company moves DHCP to SRV1. Remove the pool from R1 (or the router will keep answering) and add the helper on the interface that faces the clients:

SRV1 must have a scope (pool) for 192.168.10.0/24 with gateway 192.168.10.1, and a route back to that subnet. If SRV1 were another Cisco router, the pool would look exactly like the one above.

By default ip helper-address also forwards a few other UDP broadcasts, such as TFTP (69), DNS (53), TACACS (49), Time (37) and NetBIOS (137, 138). no ip forward-protocol udp <port> stops one of them.

3. R1 as a DHCP client toward the ISP

Full example (R1, server version)

How to verify it

R1#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
                    Hardware address/
                    User name
192.168.10.11       0100.5079.6668.01       Oct 08 2026 02:15 AM    Automatic
192.168.10.12       0100.1b44.11a3.7c       Oct 08 2026 02:31 AM    Automatic

R1#show ip dhcp pool
Pool VLAN10 :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 254
 Leased addresses               : 2
 Pending event                  : none
 1 subnet is currently in the pool :
 Current index        IP address range                    Leased addresses
 192.168.10.13        192.168.10.1     - 192.168.10.254    2

R1#show ip dhcp conflict
IP address        Detection method   Detection time          VRF
192.168.10.50     Ping               Oct 06 2026 09:12 AM

R1#show ip interface brief | include GigabitEthernet0/2
GigabitEthernet0/2     203.0.113.2     YES DHCP   up                    up

On the relay, check show running-config interface GigabitEthernet0/0 or show ip interface GigabitEthernet0/0, which lists the helper address. On the server side, the binding table shows whether the request ever arrived.

What goes wrong and how to troubleshoot it

• Clients get a 169.254.x.x address. No server answered. Is the pool there, does its network match the client subnet, and is the gateway interface up? With a relay, is the helper on the right interface and can the router ping the server?
• Clients get an address but can't leave the subnet. default-router is missing or wrong in the pool.
• The pool runs out. Check show ip dhcp pool. Exclusions may be too wide, or the lease too long for a busy guest network.
• Relayed requests get no answer. The server has no pool for the giaddr subnet, or no route back to it, or an ACL blocks UDP 67.
• Clients get addresses from the wrong server. A rogue DHCP server (often a home router plugged in by a user) is answering first. That is what DHCP snooping stops.

Common mistakes

• Putting ip helper-address on the interface toward the server instead of the one toward the clients.
• Forgetting to exclude the gateway and other static addresses, then seeing conflicts.
• Typing ip dhcp excluded-address inside the pool. It is a global command.
• Leaving a pool on the router after moving to a central server, so two servers answer.
• Writing the mask as a wildcard (0.0.0.255) on the network line. DHCP pools use a normal subnet mask.

💡 Exam tip: the blueprint asks you to configure and verify DHCP client and relay. Expect to pick the interface where ip helper-address belongs (the client-facing one), to spot a missing default-router, and to read show ip dhcp binding. Know that ip address dhcp makes a router interface a client, and that the client sends from UDP 68 to UDP 67.

Key takeaways

• Server: global ip dhcp excluded-address, then ip dhcp pool with network, default-router, dns-server.
• Relay: ip helper-address on the client-facing interface turns broadcasts into unicasts and sets giaddr.
• Client: ip address dhcp, which also adds a default route with AD 254.
• The router pings an address before offering it and logs conflicts.
• Verify with show ip dhcp binding, show ip dhcp pool and show ip dhcp conflict.

Check yourself