How to Configure a DHCP Server on a Cisco Router (Step by Step)

Step 1 — Exclude the addresses each pool must not hand out

Before you build a pool, tell the router which addresses in that subnet are already spoken for — the gateway, any servers, and static hosts. Skip this and the pool will eventually lease one of those addresses to a client, causing an IP conflict on the LAN.

Excluded-address is a global command, not part of the pool itself — configure it before (or after) the pool, it applies to the whole subnet regardless of order. If the router will serve more than one subnet, exclude the reserved addresses for each one separately.

R1(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.10
R1(config)# ip dhcp excluded-address 192.168.20.1 192.168.20.10

Step 2 — Create the pool and define the scope

A DHCP pool is a named object holding everything the router needs to answer a client request: which subnet to lease from, the default gateway to hand out, DNS servers, and how long a lease lasts. The pool name is locally significant — name it after the VLAN or subnet it serves.

'network' sets the scope the pool leases from, using a normal subnet mask (not a wildcard mask like OSPF). 'default-router' is the gateway address clients on that subnet actually use — for LAN10 that's R1's own directly-attached interface. But a pool doesn't have to live on a directly-connected subnet: R1 can also hold a pool for a subnet it never touches directly, like LAN20 hanging off a second router, R2. For that pool 'default-router' is R2's LAN-facing interface — the gateway those clients really use — not R1's own address.

'lease' takes days, hours, minutes — 'lease 0 8 0' is an 8-hour lease, handy for a lab you rebuild often.

R1(config)# ip dhcp pool LAN10
R1(dhcp-config)# network 192.168.10.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.10.1
R1(dhcp-config)# dns-server 8.8.8.8
R1(dhcp-config)# domain-name lab.local
R1(dhcp-config)# lease 0 8 0
R1(dhcp-config)# exit
R1(config)# ip dhcp pool LAN20
R1(dhcp-config)# network 192.168.20.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.20.1
R1(dhcp-config)# dns-server 8.8.8.8
R1(dhcp-config)# domain-name lab.local
R1(dhcp-config)# lease 0 8 0

Step 3 — Verify leases, and relay DHCP for a remote subnet

Once a client requests an address, confirm the router actually leased one and that the pool isn't running dry. 'show ip dhcp binding' lists every leased address, its client, and expiration; 'show ip dhcp pool' shows how many addresses in that scope are in use versus free.

LAN10 sits directly on R1, so nothing extra is needed there — the client's broadcast already arrives on a local interface. LAN20 is different: those clients hang off R2, connected to R1 only by a point-to-point link (R1 10.0.0.1 — R2 10.0.0.2). DHCP discover messages are broadcasts, and routers don't forward broadcasts by default, so R2 never passes that request on to R1 by itself.

Fix it with 'ip helper-address' on R2's client-facing interface, pointed at R1's own address on the link between the two routers (10.0.0.1) — the address of the actual DHCP server. That is not the same thing as the client subnet's own gateway (192.168.20.1), and it is not the unrelated LAN10 address either; pointing helper-address at either of those is a common mistake and won't reach the pool. Aimed correctly, it converts the broadcast into a unicast relay so the request reaches LAN20 on R1.

It's easy to type all of this correctly and still get one detail wrong — a pool network that doesn't quite match the client subnet, or a helper-address aimed at the wrong hop. Building it on real IOS and grading the running config against a known-good answer key is the fastest way to catch that before it costs you on the exam.

One requirement it's easy to miss: the server's OFFER/ACK for a relayed request is unicast back to the relay agent's address (192.168.20.1), not broadcast. Since that subnet isn't directly connected to R1, R1 needs a route to it — here a static route via R2 (10.0.0.2). Without that route every command is syntactically correct but the client still never gets a lease.

R2(config)# interface gigabitethernet0/1
R2(config-if)# ip helper-address 10.0.0.1
R2(config-if)# end
R1(config)# ip route 192.168.20.0 255.255.255.0 10.0.0.2
R1(config)# end
R1# show ip dhcp binding
R1# show ip dhcp pool LAN20

Common problems (and the fix)

Not excluding the gateway or static addresses on every pool — the pool will eventually offer one of them to a client, causing a duplicate-IP conflict. Run 'ip dhcp excluded-address' for every reserved address in every subnet you serve, before you trust the pool with real clients.

A 'default-router' that doesn't match the actual gateway on that subnet — clients lease an address but have no way off their own subnet. It must be the interface IP clients on that specific subnet actually use as their gateway; for a remote pool that's the far router's LAN interface, not the DHCP server's own address.

A pool 'network' statement that doesn't match the client subnet — wrong subnet or a mask that doesn't line up. If it's off, the router has nothing to offer on that segment and clients time out.

Forgetting 'ip helper-address' on the client-side interface for a subnet that isn't directly connected to the DHCP server — or pointing it at the wrong address, such as the client subnet's own gateway instead of the DHCP server. DHCP discover is a local broadcast; without a helper address aimed at the real server, it never crosses the router hop, and clients silently fail to get an address.

The relayed subnet leases nothing even though helper-address is set — the DHCP server has no route back to the client subnet. Because the reply is unicast to the relay's address, R1 must be able to reach 192.168.20.0/24 (a routing protocol between R1 and R2, or a static route like 'ip route 192.168.20.0 255.255.255.0 10.0.0.2').