Hands-On Lab: Configuring an IPv6 DHCP Relay Agent

This hands-on lab configures a router to relay DHCPv6 requests from a remote subnet to a centralized DHCPv6 server, mirroring the ip helper-address behavior covered earlier in this series but using IPv6's distinct relay mechanism.

DHCPv6 Relay Configurationipv6 dhcp relay destinationRemote Subnet DHCPv6

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

Lab Objective

Configure a router as a DHCPv6 relay agent, forwarding DHCPv6 requests from a remote subnet to a centralized DHCPv6 server on a different segment, and verify a client on the remote subnet successfully receives an address despite the server having no direct connection to that segment.

Lab Purpose

The DHCP relay lab covered earlier in this series used ip helper-address for IPv4. IPv6 requires a distinct, protocol-specific relay configuration, since DHCPv6 operates differently at the protocol level from DHCPv4 — understanding this separate syntax is essential for supporting centralized DHCPv6 in any multi-subnet IPv6 deployment.

Lab Topology

R1 (DHCPv6 server) ---- Gi0/0: 2001:DB8:J:1::1/64
R1 ---- Serial0/0/0 ---- Serial0/0/0 ---- R2 (relay)

R2 ---- Gi0/0: 2001:DB8:J:2::1/64 (remote
                                    subnet,
                                    clients here)

Task 1: Configure Basic IPv6 Addressing

Enable IPv6 routing and configure R1's LAN interface, the serial link, and R2's LAN interface.

Task 2: Configure R1 as a Stateful DHCPv6 Server

Configure a DHCPv6 pool on R1 covering R2's remote subnet, and apply it appropriately.

Task 3: Configure DHCPv6 Relay on R2

Configure R2's LAN-facing interface to relay DHCPv6 requests toward R1.

Task 4: Verify a Remote Client Receives an Address

Confirm a client on R2's LAN successfully obtains an address from R1's DHCPv6 pool.

Task 5: Verify the Binding on the DHCPv6 Server

Confirm R1 shows the remote client's binding, despite having no direct connection to that segment.

Solution and Verification

R1(config)# ipv6 unicast-routing
R1(config)# interface gigabitethernet0/0
R1(config-if)# ipv6 address 2001:DB8:J:1::1/64
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface serial0/0/0
R1(config-if)# ipv6 address 2001:DB8:JLINK::1/64
R1(config-if)# no shutdown

R2(config)# ipv6 unicast-routing
R2(config)# interface serial0/0/0
R2(config-if)# ipv6 address 2001:DB8:JLINK::2/64
R2(config-if)# no shutdown
R2(config-if)# exit
R2(config)# interface gigabitethernet0/0
R2(config-if)# ipv6 address 2001:DB8:J:2::1/64
R2(config-if)# no shutdown

R1(config)# ipv6 dhcp pool REMOTE-POOL
R1(config-dhcpv6)# address prefix 2001:DB8:J:2::/64
R1(config-dhcpv6)# dns-server 2001:4860:4860::8888

R1(config)# interface gigabitethernet0/0
R1(config-if)# ipv6 dhcp server REMOTE-POOL
-- Also serving its own local segment, but
-- note this pool's address range is
-- specifically for the REMOTE subnet, not
-- this local interface's own subnet --
-- DHCPv6 relay works based on prefix
-- matching, not physical interface

R2(config)# interface gigabitethernet0/0
R2(config-if)# ipv6 dhcp relay destination 2001:DB8:JLINK::1

-- Unlike IPv4's simple "ip helper-address,"
-- IPv6 uses "ipv6 dhcp relay destination"
-- -- distinct syntax reflecting DHCPv6's
-- own protocol differences from DHCPv4

RemoteClient> ipconfig /renew6

IPv6 Address: 2001:DB8:J:2::1000
DNS Servers: 2001:4860:4860::8888
-- The remote client successfully received
-- an address from R1's REMOTE-POOL,
-- despite R1 having no direct connection
-- to the 2001:DB8:J:2::/64 segment

R1# show ipv6 dhcp binding

Client: FE80::...
  IA NA: IA ID 0x00030001, T1 43200, T2 69120
    Address: 2001:DB8:J:2::1000
    preferred lifetime 86400, valid lifetime 86400
-- R1 shows the binding for the remote
-- client, confirming it is genuinely
-- serving as the DHCPv6 server for this
-- remote segment via R2's relay

Key Takeaway

DHCPv6 relay uses ipv6 dhcp relay destination rather than IPv4's ip helper-address, a syntax distinction worth remembering when migrating IPv4 relay knowledge to dual-stack or IPv6-only environments — the underlying concept remains identical to the IPv4 relay lab covered earlier in this series (converting a client's local multicast/broadcast request into a targeted unicast message toward a centralized server), but the specific command and protocol mechanics differ meaningfully between the two address families.

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

مقالات مرتبط

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.

ادامه