Hands-On Lab: Configuring a DHCP Server and DHCP Relay

This hands-on lab configures a router as a DHCP server for one subnet and configures DHCP relay (ip helper-address) so clients on a separate remote subnet can reach that same centralized server, verifying both scenarios independently.

DHCP Server Pool ConfigurationIP Helper-AddressDHCP Relay Agent

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure a router as a DHCP server for its own directly connected subnet, then configure a second router to relay DHCP requests from a remote subnet to that same centralized server, verifying clients on both subnets receive addresses correctly.

Lab Purpose

DHCP relies entirely on broadcast traffic, discussed earlier in this series, which does not cross router boundaries by default. This lab demonstrates both configuring the DHCP server itself and using ip helper-address to extend its reach to a remote subnet without deploying a second server.

Lab Topology

R1 (DHCP server) ---- Gi0/0: 192.168.70.1/24
R1 ---- Serial0/0/0 ---- Serial0/0/0 ---- R2 (relay)

R2 ---- Gi0/0: 192.168.80.1/24 (remote subnet,
                                clients here)

Task 1: Configure Basic Addressing

Configure R1's LAN interface, the serial link between R1 and R2, and R2's LAN interface.

Task 2: Configure R1 as a DHCP Server

Create a DHCP pool on R1 for its own local subnet, excluding the router's own address, and a second pool for R2's remote subnet.

Task 3: Verify Local DHCP Assignment

Confirm a client on R1's own LAN successfully receives an address directly.

Task 4: Configure DHCP Relay on R2

Configure ip helper-address on R2's LAN-facing interface, pointing to R1.

Task 5: Verify Remote DHCP Assignment via Relay

Confirm a client on R2's LAN successfully receives an address from R1's pool for that subnet, despite R1 not being directly connected to that segment.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.70.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface serial0/0/0
R1(config-if)# ip address 10.14.14.1 255.255.255.252
R1(config-if)# no shutdown

R2(config)# interface serial0/0/0
R2(config-if)# ip address 10.14.14.2 255.255.255.252
R2(config-if)# clock rate 64000
R2(config-if)# no shutdown
R2(config-if)# exit
R2(config)# interface gigabitethernet0/0
R2(config-if)# ip address 192.168.80.1 255.255.255.0
R2(config-if)# no shutdown

R1(config)# ip dhcp excluded-address 192.168.70.1 192.168.70.10
R1(config)# ip dhcp excluded-address 192.168.80.1 192.168.80.10

R1(config)# ip dhcp pool LOCAL-POOL
R1(dhcp-config)# network 192.168.70.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.70.1
R1(dhcp-config)# exit

R1(config)# ip dhcp pool REMOTE-POOL
R1(dhcp-config)# network 192.168.80.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.80.1

LocalPC (on R1's own LAN)> ipconfig /renew

IPv4 Address: 192.168.70.11
Default Gateway: 192.168.70.1
-- Direct assignment works immediately, since
-- this client shares a broadcast domain
-- directly with R1

R2(config)# interface gigabitethernet0/0
R2(config-if)# ip helper-address 10.14.14.1

-- Applied on the interface FACING the clients,
-- pointing toward R1, the actual DHCP server

RemotePC (on R2's LAN)> ipconfig /renew

IPv4 Address: 192.168.80.11
Default Gateway: 192.168.80.1
-- The remote client successfully received an
-- address from R1's REMOTE-POOL, despite R1
-- having no direct connection to this subnet

R1# show ip dhcp binding

IP address       Client-ID/Hardware address    Lease expiration
192.168.70.11     0100.5056.aa11.22             ...
192.168.80.11     0100.5056.bb33.44             ...
-- R1 shows leases for BOTH subnets, confirming
-- it is genuinely serving as the DHCP server
-- for the remote clients too, not just its
-- own local ones

Key Takeaway

R2's ip helper-address command converts the client's DHCP broadcast into a unicast packet directed specifically at R1, then relays R1's response back to the client — this single command is what allows one centralized DHCP server to serve clients across many separate subnets without deploying a dedicated server on every segment.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه