Unlock Seamless Spoke-to-Spoke Connectivity: Mastering DMVPN Phase 3 with EIGRP Summarization
A deep dive into configuring scalable and efficient enterprise WANs using dynamic tunnels and optimized EIGRP routing.
Dynamic Multipoint VPN (DMVPN) Phase 3, combined with Enhanced Interior Gateway Routing Protocol (EIGRP) summarization, offers a powerful solution for building scalable, resilient, and efficient Wide Area Networks (WANs). This configuration allows for direct spoke-to-spoke communication, reducing latency and offloading the hub router, while EIGRP summarization minimizes routing overhead and enhances network stability. This guide will walk you through the essential concepts and step-by-step configurations.
Key Highlights of This Configuration
- Direct Spoke-to-Spoke Communication: DMVPN Phase 3 utilizes NHRP (Next Hop Resolution Protocol) redirects and shortcuts, enabling spokes to establish dynamic, direct tunnels with each other, bypassing the hub for data traffic.
- Optimized Routing with EIGRP Summarization: The hub router advertises summarized routes (often a default route) to spokes, significantly reducing the size of routing tables on spoke routers and minimizing EIGRP update propagation.
- Enhanced Scalability and Stability: Configuring spokes as EIGRP stub routers, disabling split-horizon on the hub's tunnel interface for EIGRP, and careful NHRP setup contribute to a highly scalable and stable DMVPN deployment.
Understanding DMVPN Phase 3 and EIGRP Summarization
DMVPN is a Cisco IOS Software solution that allows the creation of dynamic VPN tunnels between multiple sites. Phase 3 is an evolution that builds upon previous phases by allowing for more efficient spoke-to-spoke traffic flow without requiring spoke routes to be fully present in each spoke's routing table initially. EIGRP is a robust interior gateway protocol well-suited for DMVPN environments due to its fast convergence and scalability features.
Core Components and Their Roles
A typical DMVPN Phase 3 topology illustrating hub, spokes, and potential spoke-to-spoke communication paths.
Hub Router
The hub acts as the central point for the DMVPN network. It serves as the NHRP server (NHS), where spokes register their tunnel IP-to-NBMA (Non-Broadcast Multi-Access, i.e., public IP) address mappings. In Phase 3 with EIGRP summarization, the hub is responsible for advertising summarized routes to the spokes, typically a default route, simplifying spoke routing tables.
Spoke Routers
Spoke routers are remote sites connecting to the DMVPN. They act as NHRP clients, registering with the hub. Spokes learn about other spokes' networks via the hub. In Phase 3, when a spoke needs to send traffic to another spoke, it queries the hub, receives an NHRP redirect, and then establishes a direct "shortcut" tunnel to the destination spoke. Spokes are often configured as EIGRP stub routers to limit query propagation and advertise only their local networks to the hub.
NHRP (Next Hop Resolution Protocol)
NHRP is fundamental to DMVPN. It allows routers to dynamically discover the NBMA addresses of other routers connected to the DMVPN cloud. Key NHRP messages in Phase 3 include:
- Registration: Spokes register their tunnel and NBMA addresses with the NHS (hub).
- Resolution: A spoke queries the NHS to find the NBMA address of another spoke's tunnel IP.
- Redirect: The hub, upon receiving traffic from one spoke destined to another spoke (for which it has a more specific route via the destination spoke), sends an NHRP Redirect message to the initiating spoke. This informs the source spoke to establish a direct path.
- Shortcut Switching: Enabled on spoke tunnel interfaces, this allows the spoke to create direct spoke-to-spoke tunnels upon receiving an NHRP redirect or learning a route via NHRP.
EIGRP (Enhanced Interior Gateway Routing Protocol)
EIGRP is used as the dynamic routing protocol over the DMVPN tunnels. Key EIGRP configurations include:
- Autonomous System (AS): Must be consistent across all DMVPN routers.
- Network Advertisement: Both tunnel interface networks and local LAN networks are advertised.
- Summarization: Configured on the hub's tunnel interface to send a summary (e.g., default route) to spokes. This is often done using `summary-address` under the EIGRP address-family interface configuration.
- Split Horizon: Must be disabled on the hub's tunnel interface for EIGRP to allow routes learned from one spoke to be advertised to other spokes.
- Stub Routing: Spokes are configured as `eigrp stub` routers, preventing them from becoming transit points for EIGRP queries and advertising only specified routes (e.g., connected, summary).
Step-by-Step Configuration Guide
Step 1: Prerequisite Checks and Topology Overview
Before you begin, ensure:
- All routers (hub and spokes) have IP connectivity to the internet or underlying transport network.
- You have a unique EIGRP Autonomous System number.
- You have planned your IP addressing scheme for tunnel interfaces and LANs.
- Cisco IOS devices support DMVPN Phase 3 features (typically IOS 12.4(6)T or later for basic Phase 3, newer versions for advanced features and scalability).
Our example uses EIGRP Named Mode, which provides a hierarchical configuration structure.
Step 2: Hub Router Configuration
The hub router is configured as an NHRP server and performs EIGRP route summarization.
Tunnel Interface Setup (mGRE, NHRP)
interface Tunnel0
ip address 10.100.0.1 255.255.255.0 ! Tunnel IP address
no ip redirects
ip nhrp authentication DMVPN_AUTH_KEY ! Optional: NHRP authentication
ip nhrp map multicast dynamic ! Allow dynamic mapping for multicast (needed for routing protocols)
ip nhrp network-id 100 ! Unique NHRP network identifier
ip nhrp redirect ! Enables NHRP redirect messages for Phase 3
tunnel source GigabitEthernet0/0 ! Physical interface used for the tunnel (WAN interface)
tunnel mode gre multipoint ! Defines the tunnel as multipoint GRE
tunnel key 123456 ! Optional: GRE tunnel key for simple security (match on spokes)
! For IPSec, additional crypto configuration is required
ip mtu 1400 ! Recommended to avoid fragmentation issues
ip tcp adjust-mss 1360 ! Adjust MSS for TCP sessions over the tunnel
endEIGRP Configuration (Named Mode)
router eigrp ITHY_DMVPN
!
address-family ipv4 unicast autonomous-system 100
!
network 10.100.0.0 0.0.0.255 ! Advertise the tunnel network
network 192.168.0.0 ! Advertise Hub's local LAN (example)
!
af-interface Tunnel0
summary-address 0.0.0.0 0.0.0.0 ! Advertise a default route to spokes
no split-horizon ! CRUCIAL: Disable EIGRP split-horizon on the hub's mGRE tunnel
exit-af-interface
!
topology base
exit-sf-topology
exit-address-family
endNote: The `no split-horizon` command under `af-interface Tunnel0` is critical. It allows the hub to advertise routes learned from one spoke back out the same tunnel interface to other spokes.
Step 3: Spoke Router Configuration
Spoke routers are configured as NHRP clients and EIGRP stub routers.
Tunnel Interface Setup (mGRE, NHRP mapping to Hub)
Configuration for Spoke 1 (repeat with unique IPs for other spokes):
interface Tunnel0
ip address 10.100.0.2 255.255.255.0 ! Unique tunnel IP for this spoke
no ip redirects
ip nhrp authentication DMVPN_AUTH_KEY ! Match hub's NHRP authentication
ip nhrp map 10.100.0.1 <HUB_PUBLIC_IP_ADDRESS> ! Static mapping for Hub's tunnel IP to its NBMA (public) IP
ip nhrp map multicast <HUB_PUBLIC_IP_ADDRESS> ! Send multicast traffic (like EIGRP hellos) to Hub's NBMA IP
ip nhrp network-id 100 ! Match hub's NHRP network ID
ip nhrp nhs 10.100.0.1 ! Define the Next Hop Server (Hub's tunnel IP)
ip nhrp shortcut ! Enable NHRP shortcut switching for direct spoke-to-spoke tunnels
tunnel source GigabitEthernet0/0 ! Physical interface used for the tunnel (WAN interface)
tunnel mode gre multipoint ! Defines the tunnel as multipoint GRE (spokes can also use p2p GRE if preferred, but mGRE is common)
tunnel key 123456 ! Match hub's tunnel key
ip mtu 1400
ip tcp adjust-mss 1360
endEIGRP Configuration (Named Mode, Stub)
router eigrp ITHY_DMVPN
!
address-family ipv4 unicast autonomous-system 100
!
network 10.100.0.0 0.0.0.255 ! Advertise the tunnel network
network 10.1.1.0 ! Advertise Spoke's local LAN (e.g., 10.1.1.0/24)
!
eigrp stub connected summary ! Configure spoke as an EIGRP stub router
! This tells the spoke to advertise only connected and summary routes
! and not to propagate queries from the hub to other spokes.
!
af-interface Tunnel0
! No summary address here typically; spokes advertise specific LANs to the hub
! Split-horizon is typically left enabled (default) on spokes or not applicable in the same way
exit-af-interface
!
topology base
exit-sf-topology
exit-address-family
endThe `eigrp stub` command significantly improves scalability and stability by limiting the scope of EIGRP queries in the DMVPN network.
Key Considerations and Best Practices
no auto-summary: While EIGRP named mode defaults to `no auto-summary`, if using classic EIGRP, always issue `no auto-summary` under the EIGRP process to prevent unintended summarization at classful boundaries. Manual summarization provides precise control.- NHRP Holdtime: Default NHRP holdtime is 7200 seconds (2 hours). Adjust `ip nhrp holdtime ` on tunnel interfaces if needed, ensuring consistency or appropriate values for registration refresh intervals.
- IPSec for Security: The configurations above focus on GRE and EIGRP. For production environments, always secure DMVPN tunnels with IPSec. This involves configuring ISAKMP policies, IPSec transform sets, and crypto profiles applied to the tunnel interface.
- MTU and MSS: GRE and IPSec add overhead. `ip mtu 1400` and `ip tcp adjust-mss 1360` are common starting points to avoid IP fragmentation over the tunnel. Test and adjust based on your specific encapsulation.
- Scalability: For very large DMVPN deployments (hundreds or thousands of spokes), consider hierarchical DMVPN designs or advanced Cisco IOS XE features that enhance EIGRP scalability for DMVPN.
Visualizing DMVPN Phase 3 and EIGRP Summarization
Comparative Analysis of DMVPN Phases
This radar chart provides a conceptual comparison of DMVPN Phases 1, 2, and 3 across several key operational characteristics. Higher values generally indicate better performance or capability in that aspect. Note that "Config Complexity" refers to the relative effort; a higher value means more complex.
DMVPN Phase 3 generally offers the best balance for spoke-to-spoke efficiency and scalability, though it involves a slightly more intricate configuration, especially regarding NHRP interactions like redirects and shortcuts.
DMVPN Phase 3 EIGRP Summarization Mindmap
This mindmap illustrates the key components and relationships in a DMVPN Phase 3 setup utilizing EIGRP with summarization.
with EIGRP Summarization"] id1["Hub Configuration"] id1a["mGRE Tunnel Interface"] id1b["NHRP Server Role"] id1b1["ip nhrp network-id"] id1b2["ip nhrp redirect"] id1b3["ip nhrp map multicast dynamic"] id1c["EIGRP (Named Mode)"] id1c1["Advertise Tunnel & Local LANs"] id1c2["af-interface Tunnel0"] id1c2a["summary-address (e.g., 0.0.0.0/0)"] id1c2b["no split-horizon"] id2["Spoke Configuration"] id2a["mGRE Tunnel Interface"] id2b["NHRP Client Role"] id2b1["ip nhrp network-id (match hub)"] id2b2["ip nhrp nhs <hub_tunnel_ip>"] id2b3["ip nhrp map <hub_tunnel_ip> <hub_nbma_ip>"] id2b4["ip nhrp shortcut"] id2c["EIGRP (Named Mode)"] id2c1["Advertise Tunnel & Local LANs"] id2c2["eigrp stub connected summary"] id3["Key Protocols & Technologies"] id3a["GRE (Multipoint)"] id3b["NHRP (Resolution, Redirect, Shortcut)"] id3c["EIGRP (Routing Protocol)"] id4["Core Benefits"] id4a["Direct Spoke-to-Spoke Traffic"] id4b["Reduced Hub Bottleneck"] id4c["Scalable WAN Design"] id4d["Simplified Spoke Routing (via Summary/Default Route)"] id5["Important Settings"] id5a["Consistent NHRP Network ID & Auth"] id5b["Tunnel MTU/MSS Adjustment"] id5c["IPSec for Security (Recommended)"]
The mindmap visually structures the configuration, highlighting how different elements interoperate to achieve the desired DMVPN Phase 3 functionality with EIGRP summarization.
Configuration Verification
After applying the configurations, verify the DMVPN and EIGRP operation using these commands:
Hub Verification Commands
show ip nhrporshow ip nhrp brief: Displays NHRP cache entries, showing registered spokes.show dmvpn: Provides a summary of DMVPN session status including peer NBMA address, state, and uptime.show ip eigrp neighbors [detail](orshow eigrp address-family ipv4 neighbors [detail]for named mode): Verifies EIGRP adjacencies with spokes over the tunnel interface.show ip route eigrp: Checks routes learned from spokes and routes advertised (including the summary).show ip interface Tunnel0: Verifies tunnel interface status.
Spoke Verification Commands
show ip nhrporshow ip nhrp brief: Shows NHRP registration with the hub and any dynamic spoke-to-spoke mappings.show ip nhrp redirect: Shows if any NHRP redirect messages have been received/processed.show ip nhrp shortcut: Displays active NHRP shortcut SAs (Security Associations, if IPSec is used) or tunnels.show dmvpn: Similar to hub, shows DMVPN session to the hub and potentially other spokes.show ip eigrp neighbors [detail](orshow eigrp address-family ipv4 neighbors [detail]): Verifies EIGRP adjacency with the hub.show ip route eigrp: Should show the summary route (e.g., default route) learned from the hub and potentially specific routes to other spokes if direct tunnels are active.ping <other_spoke_lan_ip>andtraceroute <other_spoke_lan_ip>: Test spoke-to-spoke connectivity. The traceroute should show a direct path after the first few packets (once the shortcut is established).
Common Verification Commands Table
This table summarizes key commands and their expected insights:
| Command | Router | Purpose | Expected Output Snippet/Indication |
|---|---|---|---|
show ip nhrp brief |
Hub & Spoke | Verify NHRP registrations and mappings | Hub: Lists all registered spokes. Spoke: Shows hub mapping, and dynamic spoke mappings after S2S traffic. |
show dmvpn |
Hub & Spoke | Overview of DMVPN tunnel status | Interface, Peer NBMA Addr, State (UP/DOWN), UpDn Time. |
show eigrp address-family ipv4 neighbors |
Hub & Spoke | Verify EIGRP adjacencies | Lists EIGRP neighbors, their tunnel IPs, uptime, SRTT, RTO, Q Cnt. |
show ip route eigrp |
Spoke | Verify learned routes | Should primarily show the summary/default route from the hub. |
show ip route eigrp |
Hub | Verify learned routes | Should show specific LAN routes from all spokes. |
show ip nhrp redirect |
Spoke | Check NHRP redirect activity | Counters for redirect messages received/sent. |
show ip nhrp stats |
Hub & Spoke | Detailed NHRP statistics | Counters for various NHRP packet types (Registration, Resolution, Redirect etc.) |
Understanding the Configuration Through a Video Example
For a visual demonstration and further context on DMVPN Phase 3 with EIGRP, the following video provides a practical walkthrough. It discusses the setup of DMVPN Phase 3 along with EIGRP, which aligns well with the concepts covered in this guide. Watching how an expert configures and verifies these components can solidify your understanding.
Video demonstrating a DMVPN Phase 3 with EIGRP setup.
This video can help you visualize the command-line interactions and see the dynamic nature of DMVPN Phase 3, especially how EIGRP operates within this framework to establish connectivity and propagate routing information, including summarization aspects.
Frequently Asked Questions (FAQ)
1. Why is `no ip split-horizon eigrp ` (or `no split-horizon` in af-interface) needed on the hub's tunnel interface?
EIGRP's split-horizon rule prevents a router from advertising a route back out the same interface on which it was learned. In a DMVPN hub-and-spoke topology, the hub learns routes from all spokes via its single mGRE tunnel interface. To enable spoke-to-spoke communication where spokes learn about each other's networks via the hub, split-horizon must be disabled on the hub's tunnel interface for EIGRP. This allows the hub to reflect routes learned from one spoke to other spokes over that same tunnel interface.
2. What is the benefit of `eigrp stub` on spoke routers?
Configuring spokes as `eigrp stub` routers significantly enhances network scalability and stability. Stub routers typically only advertise connected or summary routes and do not propagate EIGRP queries from the hub to other downstream routers (if any). This reduces the EIGRP query scope, minimizes CPU utilization on routers during topology changes, and prevents spokes from becoming transit paths for EIGRP traffic between other parts of the network, simplifying the routing topology.
3. How does NHRP `redirect` and `shortcut` work in DMVPN Phase 3?
In DMVPN Phase 3:
- When a spoke (SpokeA) sends traffic to another spoke (SpokeB) via the hub, the hub, upon receiving this traffic, notices it has a more specific route to SpokeB's LAN via SpokeB's tunnel.
- The hub forwards the initial packet(s) but also sends an NHRP Redirect message to SpokeA. This message tells SpokeA that there's a better path to SpokeB's LAN, directly via SpokeB's tunnel IP.
- SpokeA, upon receiving the redirect and having `ip nhrp shortcut` enabled on its tunnel, will then send an NHRP Resolution Request for SpokeB's tunnel IP to find SpokeB's NBMA (public) address.
- Once resolved, SpokeA establishes a direct dynamic GRE tunnel (a shortcut) to SpokeB, and subsequent traffic flows directly, bypassing the hub. The routing table on SpokeA is updated with a specific host route for SpokeB's LAN IP via SpokeB's tunnel IP through NHRP.
4. Can I use OSPF instead of EIGRP with DMVPN Phase 3?
Yes, OSPF can be used with DMVPN Phase 3. However, OSPF has different design considerations. For example, the OSPF network type on the tunnel interface is crucial (often set to `broadcast` or `point-to-multipoint`). DR/BDR elections (in broadcast mode) and LSA flooding behavior need careful management in a large DMVPN cloud. Summarization with OSPF is also handled differently, typically at ABRs (Area Border Routers). While EIGRP is often favored for its simplicity in DMVPN, OSPF is a viable alternative with proper design.
5. What's the difference between `ip summary-address eigrp` (classic) and `summary-address` under `af-interface` (named mode)?
Both commands achieve EIGRP route summarization on an interface.
ip summary-address eigrp <as-number> <address> <mask>is the traditional command used in classic EIGRP mode, applied directly under the interface configuration.summary-address <address> <mask>is used within EIGRP Named Mode, under the `address-family ipv4 unicast autonomous-system <as-number> af-interface <interface-type> <interface-number>` sub-configuration mode.
Named Mode EIGRP provides a more structured and hierarchical configuration, consolidating all EIGRP settings under the `router eigrp <name>` process. Functionally, for summarization, they serve the same purpose but are applied in different configuration contexts depending on whether you are using classic or named EIGRP.
Recommended Further Exploration
- How can I secure DMVPN Phase 3 deployments using IPSec with IKEv2 for robust encryption and authentication?
- What are the best practices for implementing dual-hub redundancy in a DMVPN Phase 3 network to ensure high availability?
- What are common troubleshooting steps for resolving connectivity or routing issues in DMVPN Phase 3 with EIGRP?
- How do advanced EIGRP features, such as EIGRP Over The Top (OTP), enhance scalability in large DMVPN deployments?
References
journey2theccie.wordpress.com
journey2theccie.wordpress.com
thenetworkseal.wordpress.com
networkingjournalblog.wordpress.com
journey2theccie.wordpress.com
Last updated May 12, 2025