LogoفارسیFA

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.

EIGRP over mGRE TunnelDMVPN Dynamic Routing IntegrationSpoke Route Advertisement

~4 min read · Updated Sep 27, 2026

Lab Objective

Enable EIGRP directly on the DMVPN tunnel interfaces built in earlier labs, verify the hub forms EIGRP neighbor relationships with each spoke automatically as they register via NHRP, and confirm each spoke's LAN is learned by the hub and other spokes without any hub-side per-spoke static configuration.

Lab Purpose

The DMVPN labs covered earlier in this series established NHRP-based tunnel connectivity but used no dynamic routing protocol, leaving actual route propagation unaddressed. Running EIGRP directly over the mGRE tunnel interface combines DMVPN's dynamic tunnel formation with EIGRP's dynamic route learning, letting new spokes be added with routing working automatically the moment they register.

Lab Topology

Hub ---- Tunnel0 (mGRE): 172.16.200.1/24
Spoke1 ---- Tunnel0: 172.16.200.2/24
Spoke2 ---- Tunnel0: 172.16.200.3/24

Spoke1's LAN: 192.168.11.0/24
Spoke2's LAN: 192.168.12.0/24
Hub's LAN: 192.168.10.0/24

DMVPN tunnels already established and
registered via NHRP, as in earlier labs

Task 1: Enable EIGRP on the Hub's Tunnel and LAN Interfaces

Configure EIGRP AS 100 on the hub, including the tunnel interface and its LAN.

Task 2: Enable EIGRP on Each Spoke's Tunnel and LAN Interfaces

Configure the identical EIGRP AS on both spokes, including their tunnel interfaces and respective LANs.

Task 3: Verify EIGRP Neighbor Relationships Form Across the Tunnel

Confirm the hub shows EIGRP neighbor relationships with both spokes over Tunnel0.

Task 4: Verify Each Spoke's LAN Is Learned by the Hub

Confirm the hub's routing table includes both spoke LANs, learned dynamically via EIGRP.

Task 5: Verify Spoke-to-Spoke Connectivity Without Manual Route Configuration

Confirm Spoke1 can reach Spoke2's LAN, with the hub relaying the traffic since EIGRP hub-and-spoke does not automatically build spoke-to-spoke shortcuts the way DMVPN Phase 3 NHRP does.

Solution and Verification

Hub(config)# router eigrp 100
Hub(config-router)# network 172.16.200.0 0.0.0.255
Hub(config-router)# network 192.168.10.0 0.0.0.255
Hub(config-router)# no auto-summary

Spoke1(config)# router eigrp 100
Spoke1(config-router)# network 172.16.200.0 0.0.0.255
Spoke1(config-router)# network 192.168.11.0 0.0.0.255
Spoke1(config-router)# no auto-summary

Spoke2(config)# router eigrp 100
Spoke2(config-router)# network 172.16.200.0 0.0.0.255
Spoke2(config-router)# network 192.168.12.0 0.0.0.255
Spoke2(config-router)# no auto-summary

-- No neighbor statements needed anywhere --
-- EIGRP relies on multicast hello packets,
-- which the mGRE tunnel interface, already
-- established via NHRP in earlier labs,
-- transports normally across the DMVPN cloud

Hub# show ip eigrp neighbors

H   Address         Interface   Hold Uptime
0   172.16.200.2    Tu0          13   00:03:22
1   172.16.200.3    Tu0          14   00:02:05
-- Both spokes formed EIGRP neighbor
-- relationships with the hub over the
-- shared multipoint tunnel interface,
-- entirely through automatic discovery
-- rather than any manually configured
-- neighbor statement

Hub# show ip route eigrp

D    192.168.11.0/24 [90/28160256] via 172.16.200.2, Tunnel0
D    192.168.12.0/24 [90/28160256] via 172.16.200.3, Tunnel0
-- Both spoke LANs learned dynamically,
-- requiring no static configuration on
-- the hub referencing either spoke
-- individually

Spoke1-LAN-PC> traceroute 192.168.12.10

  1  172.16.200.1 (Hub, via Tunnel0)
  2  192.168.12.10 (Spoke2's host)
-- Traffic flows through the hub, since
-- basic EIGRP-over-DMVPN provides no
-- spoke-to-spoke shortcut mechanism on its
-- own -- achieving direct spoke-to-spoke
-- paths would require adding NHRP shortcut
-- and redirect, as covered in the Phase 3
-- DMVPN lab, layered on top of this EIGRP
-- configuration

Key Takeaway

EIGRP requires no special configuration to operate correctly over a DMVPN mGRE tunnel interface — it treats the tunnel as an ordinary multi-access network and forms neighbors via its normal multicast hello discovery, meaning any new spoke added to the DMVPN cloud with matching EIGRP configuration automatically becomes a full routing participant the moment its NHRP registration and EIGRP hello exchange complete, with no hub-side per-spoke configuration ever required.

Written & researched by Dr. Shahin Siami

Related Articles

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.

Continue

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.

Continue

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.

Continue

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.

Continue

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.

Continue

Hands-On Lab: Configuring Cisco DNA Center Assurance-Style Health Scoring (Simulated via IP SLA and EEM)

This hands-on lab combines IP SLA monitoring with an EEM applet to simulate a simplified assurance-style health check, automatically classifying a link's health based on measured performance thresholds and logging a clear status change when the link degrades.

Continue
Previous ArticleNext Article