17.1 Enterprise VPN Technologies (DMVPN Phase 1/2/3 & FlexVPN)
Key Takeaways
- Dynamic Multipoint VPN (DMVPN) combines Multipoint GRE (mGRE), Next Hop Resolution Protocol (NHRP, RFC 2332), and IPsec crypto profiles to build scalable, on-demand multipoint overlay networks over public or private transport underlays without static point-to-point tunnel meshes.
- DMVPN Phase 1 implements mGRE on the hub and point-to-point GRE on spokes, requiring all spoke-to-spoke data traffic to transit the central hub and supporting full route summarization and default routing at the hub.
- DMVPN Phase 2 configures mGRE on all hubs and spokes to enable direct on-demand spoke-to-spoke data tunnels; however, it requires spokes to retain specific route next-hops (no route summarization) and requires disabling next-hop rewriting (e.g., 'no ip next-hop-self' in EIGRP/BGP).
- DMVPN Phase 3 resolves Phase 2 scalability limits by introducing NHRP Redirect ('ip nhrp redirect' on hub) and NHRP Shortcut ('ip nhrp shortcut' on spokes), allowing hierarchical route summarization/default routing at the hub while dynamically installing shortcut CEF routes ('%' routes) for direct spoke-to-spoke data forwarding.
- Cisco FlexVPN standardizes enterprise VPN architecture using IKEv2 (RFC 7296), replacing proprietary NHRP/mGRE constructs with dynamic point-to-point Virtual-Access interfaces cloned from a Virtual-Template, supporting unified site-to-site, remote-access, and hub-and-spoke topologies with dynamic BGP or EIGRP routing.
Last updated: August 2026
17.1 Enterprise VPN Technologies (DMVPN Phase 1/2/3 & FlexVPN)
Core Blueprint Focus: Cisco 350-401 ENCOR v1.2 topic 2.2.b (GRE and IPsec tunneling) and topic 5.4.a (threat defense) require network engineers to design, configure, and troubleshoot enterprise overlay VPN architectures. Candidates must master the cryptographic and protocol foundations of Dynamic Multipoint VPN (DMVPN)—including Multipoint GRE (mGRE), Next Hop Resolution Protocol (NHRP RFC 2332), and IPsec crypto profiles—the operational differences across DMVPN Phase 1, Phase 2, and Phase 3, routing protocol behavior (EIGRP, OSPF, BGP), and the next-generation Cisco FlexVPN framework built on IKEv2.
In large-scale enterprise wide-area networks (WANs), connecting hundreds or thousands of branch offices using traditional point-to-point Generic Routing Encapsulation (GRE) over IPsec tunnels creates severe configuration scaling bottlenecks. A full-mesh topology of $N$ sites requires $\frac{N(N-1)}{2}$ static tunnel interfaces, crypto maps, and routing adjacencies. Cisco Dynamic Multipoint VPN (DMVPN) and FlexVPN solve this operational bottleneck by establishing dynamic, scalable multipoint overlay networks where spoke-to-spoke tunnels are provisioned automatically on-demand.
+---------------------------------------------------------------------------------------------------+
| ENTERPRISE OVERLAY VPN EVOLUTION |
+---------------------------------------------------------------------------------------------------+
| |
| [ LEGACY STATIC P2P GRE/IPSEC ] [ DYNAMIC MULTIPOINT VPN (DMVPN) ] |
| - N*(N-1)/2 static tunnel interfaces. - Single mGRE interface per router. |
| - Manual IPsec crypto maps per peer. - Dynamic spoke registration via NHRP (RFC 2332). |
| - High management overhead. - On-demand spoke-to-spoke IPsec tunnels. |
| - Hub interface saturation. - Phase 1 (Hub-and-Spoke), Phase 2/3 (Spoke-to-Spoke).|
| |
| ================================== CISCO FLEXVPN (IKEv2) ====================================== |
| - Standardized IKEv2 framework (RFC 7296) replacing legacy IKEv1 / proprietary NHRP. |
| - Dynamic Virtual-Access interfaces cloned on-demand from Virtual-Template configurations. |
| - Unified engine: Site-to-Site, Remote Access (AnyConnect), and Hub-and-Spoke in one framework. |
| - Native dynamic routing integration via BGP dynamic neighbors and EIGRP Named Mode. |
+---------------------------------------------------------------------------------------------------+
1. Core DMVPN Building Blocks: mGRE, NHRP, and IPsec
DMVPN is not a single standalone protocol; it is a synergistic architecture combining three foundational networking technologies:
- Multipoint Generic Routing Encapsulation (mGRE): Data plane encapsulation.
- Next Hop Resolution Protocol (NHRP - RFC 2332): Control plane address resolution.
- IPsec Crypto Profiles: Security plane encryption, authentication, and anti-replay protection.
+---------------------------------------------------------------------------------------------------+
| DMVPN THREE-PILLAR ARCHITECTURE |
+---------------------------------------------------------------------------------------------------+
| |
| +---------------------------------------------------------------------------------------------+ |
| | 1. MULTIPOINT GRE (mGRE) [DATA PLANE OVERLAY] | |
| | - Single virtual tunnel interface (e.g., 'interface Tunnel0') handles multiple endpoints. | |
| | - Uses 'tunnel mode gre multipoint' instead of static point-to-point destination. | |
| | - Encapsulates unicast and multicast Layer 3 packets inside IP underlay headers. | |
| +---------------------------------------------------------------------------------------------+ |
| | |
| v |
| +---------------------------------------------------------------------------------------------+ |
| | 2. NEXT HOP RESOLUTION PROTOCOL (NHRP - RFC 2332) [CONTROL PLANE MAPPING] | |
| | - Maps Logical Tunnel (Overlay IP) to Physical Public Underlay (NBMA IP). | |
| | - Hub operates as Next Hop Server (NHS); Spokes operate as Next Hop Clients (NHCs). | |
| | - Dynamic NHRP Registration, NHRP Resolution Requests/Replies, Redirects, and Shortcuts. | |
| +---------------------------------------------------------------------------------------------+ |
| | |
| v |
| +---------------------------------------------------------------------------------------------+ |
| | 3. IPSEC CRYPTO PROFILES [SECURITY PLANE ENCRYPTION] | |
| | - Dynamically encrypts mGRE tunnel payloads without static crypto map statements. | |
| | - Bound directly to tunnel interface: 'tunnel protection ipsec profile <NAME>'. | |
| | - Uses IPsec Transport Mode (saves 20 bytes IPv4 header overhead vs. Tunnel Mode). | |
| +---------------------------------------------------------------------------------------------+ |
+---------------------------------------------------------------------------------------------------+
Multipoint GRE (mGRE)
Standard GRE point-to-point tunnels require a dedicated interface Tunnel<N> with explicit tunnel source and tunnel destination commands configured for every peer. In contrast, mGRE configures a single tunnel interface with tunnel mode gre multipoint:
- The tunnel has a fixed source IP/interface, but no static destination IP.
- When sending packets, mGRE relies on NHRP to dynamically look up the public Non-Broadcast Multi-Access (NBMA) IP address associated with the destination overlay IP.
- Enables carrying multicast routing updates (OSPF, EIGRP) and non-IP traffic over public IPv4/IPv6 underlays.
Next Hop Resolution Protocol (NHRP - RFC 2332)
NHRP functions as the Layer 3 dynamic ARP equivalent for Non-Broadcast Multi-Access (NBMA) overlay networks. It dynamically maps Overlay (Tunnel) IP addresses (private enterprise subnets, e.g., 172.16.1.X) to Underlay (NBMA) IP addresses (public ISP routable IPs, e.g., 198.51.100.X).
+---------------------------------------------------------------------------------------------------+
| NHRP PROTOCOL TRANSACTION TYPES |
+---------------------------------------------------------------------------------------------------+
| NHRP Message Type | Sender -> Receiver | Operational Purpose |
| :--------------------- | :--------------------- | :---------------------------------------------- |
| **Registration Req** | Spoke (NHC) -> Hub(NHS)| Registers the Spoke's Tunnel IP and NBMA IP |
| | | in the Hub's NHRP dynamic cache table. |
| **Registration Reply** | Hub (NHS) -> Spoke(NHC)| Confirms successful registration in NHS cache. |
| **Resolution Request** | Spoke -> NHS / Spoke | Queries the NBMA physical IP address of a |
| | | target destination Spoke Tunnel IP. |
| **Resolution Reply** | NHS / Spoke -> Spoke | Delivers requested Tunnel-to-NBMA IP mapping. |
| **NHRP Redirect** | Hub (NHS) -> Spoke | Instructs Spoke 1 that a direct path to Spoke 2 |
| **(Phase 3 Only)** | | is available (triggered on traffic tromboning). |
| **NHRP Purge** | NHS -> NHC | Invalidates stale cache entries on topology change.|
+---------------------------------------------------------------------------------------------------+
IPsec Crypto Profiles & Transport Mode Optimization
Traditional site-to-site IPsec uses static crypto maps applied to physical interfaces. In DMVPN, security is applied dynamically via IPsec Crypto Profiles attached directly to the mGRE tunnel:
- Transport Mode vs. Tunnel Mode: Standard IPsec Tunnel Mode encapsulates the packet with an extra outer IP header (adding 20 bytes). Because GRE already encapsulates the packet with an outer IP header, using IPsec Transport Mode (
mode transportin the transform set) protects the GRE packet without adding a second redundant IP header. This saves 20 bytes per packet, significantly reducing WAN MTU fragmentation.
Loading diagram...
2. DMVPN Phase Evolution: Phase 1 vs. Phase 2 vs. Phase 3
DMVPN evolved across three distinct phases to improve scalability, routing hierarchy, and spoke-to-spoke forwarding efficiency.
+---------------------------------------------------------------------------------------------------+
| DMVPN PHASE 1, 2, AND 3 COMPARISON MATRIX |
+---------------------------------------------------------------------------------------------------+
| Architectural Feature | DMVPN Phase 1 | DMVPN Phase 2 | DMVPN Phase 3 |
| :---------------------- | :---------------------- | :---------------------- | :------------------ |
| **Hub Interface Mode** | `mGRE` | `mGRE` | `mGRE` |
| **Spoke Interface Mode**| Point-to-Point `p2p GRE` | `mGRE` | `mGRE` |
| **Spoke-to-Spoke Data** | **No** (Traverses Hub) | **Yes** (Direct Tunnel) | **Yes** (Direct) |
| **Spoke NHRP Behavior** | NHC Registration only | NHRP Resolution Request | NHRP Shortcut & |
| | (No Resolution) | to Hub for peer NBMA | NHRP Redirect |
| **Route Summarization** | **Full Supported** | **NOT Supported** | **Full Supported** |
| **at Hub (Default Rt)** | (Spokes point to Hub) | (Spokes need /32 or LAN)| (Summary / Default) |
| **Next-Hop in Spoke** | Rewritten to Hub IP | Preserved as Originating| Hub IP in RIB; |
| **Routing Table** | | Spoke Tunnel IP | Dynamic Shortcut in FIB|
| **Key Hub CLI Command** | Standard NHRP Config | `no ip next-hop-self` | `ip nhrp redirect` |
| **Key Spoke CLI Command**| Static `tunnel dest` | `tunnel mode gre multi` | `ip nhrp shortcut` |
+---------------------------------------------------------------------------------------------------+
+---------------------------------------------------------------------------------------------------+
| DMVPN DATA PLANE FORWARDING TOPOLOGIES |
+---------------------------------------------------------------------------------------------------+
| |
| DMVPN PHASE 1: HUB-AND-SPOKE ONLY |
| [ Spoke 1 (p2p) ] <==== Data Traffic ====> [ HUB (mGRE) ] <==== Data Traffic ====> [ Spoke 2 ] |
| (All spoke-to-spoke packets trombone through the central hub; hub is bandwidth bottleneck) |
| |
| DMVPN PHASE 2: DYNAMIC SPOKE-TO-SPOKE (FLAT ROUTING) |
| [ Spoke 1 (mGRE) ] ---------- Control Plane (Routing/NHRP) ---------> [ HUB (mGRE) ] |
| || || |
| +==================== Direct Data Tunnel (On-Demand) ===============+ (Spoke 2) |
| (Spoke 1 queries Hub for Spoke 2 NBMA; builds direct IPsec tunnel; requires specific routes) |
| |
| DMVPN PHASE 3: HIERARCHICAL SHORTCUT ROUTING (SUMMARIZED) |
| [ Spoke 1 (mGRE) ] ----- 1. Initial Packet to Default Route ------> [ HUB (mGRE) ] |
| || <---- 2. NHRP Redirect ("Direct Path Exists") --- || |
| || || |
| +--- 3. NHRP Resolution Req/Reply -> 4. Install Shortcut (%) ----->+ (Spoke 2) |
| (Hub sends NHRP Redirect; Spoke installs dynamic CEF shortcut route; full summarization supported)|
+---------------------------------------------------------------------------------------------------+
DMVPN Phase 1 Mechanics
- Design: Hub uses mGRE (
tunnel mode gre multipoint), while all Spokes use standard point-to-point GRE (tunnel mode gre ipwith statictunnel destination <Hub-NBMA>). - Data Path: Hub-and-Spoke strictly. When Spoke 1 sends data to Spoke 2, traffic flows Spoke 1 $\to$ Hub $\to$ Spoke 2.
- Routing Rules: Highly scalable routing. The Hub can summarize all spoke subnets into a single summary route or inject a default route (
0.0.0.0/0). Spokes only maintain an adjacency with the Hub. - Limitation: Hub interface bandwidth and processing double for all spoke-to-spoke traffic (traffic tromboning/hairpinning).
DMVPN Phase 2 Mechanics
- Design: Both Hub and Spokes use mGRE (
tunnel mode gre multipoint). - Data Path: Direct Spoke-to-Spoke tunnels. Spoke 1 sends initial NHRP Resolution Request to the Hub to learn Spoke 2's NBMA IP, then dynamically establishes an IPsec tunnel directly to Spoke 2.
- The Routing Hurdle in Phase 2:
- Cisco Express Forwarding (CEF) triggers an NHRP resolution only if the routing table's next-hop IP is the destination Spoke's Tunnel IP.
- If the Hub summarizes routes or rewrites the routing next-hop to itself (
ip next-hop-self), Spoke 1 forwards all packets to the Hub, and spoke-to-spoke tunnels never trigger. - Therefore, route summarization is impossible on the Hub in Phase 2. The Hub must advertise every spoke LAN subnet with the original Spoke's next-hop preserved (
no ip next-hop-self eigrp <AS>in EIGRP, or BGP Route Reflector next-hop unchanged). - In large networks, spoke routing tables become huge, causing memory exhaustion and SPF/DUAL recalculation storms.
DMVPN Phase 3 Mechanics: NHRP Redirect & Shortcut
DMVPN Phase 3 overcomes the Phase 2 routing bottleneck by decoupling routing table next-hops from CEF forwarding next-hops.
- Hub CLI Command:
ip nhrp redirecton the Hub tunnel interface. - Spoke CLI Command:
ip nhrp shortcuton all Spoke tunnel interfaces. - Operational Forwarding Sequence:
- Spoke 1 holds a default route (
0.0.0.0/0) or summary route pointing to the Hub. Spoke 1 forwards data destined for Spoke 2's LAN to the Hub. - The Hub receives the packet on
Tunnel0and routes it out the sameTunnel0interface toward Spoke 2. - Detecting that the ingress and egress interfaces are identical, the Hub forwards the data packet to Spoke 2 and simultaneously sends an NHRP Redirect packet to Spoke 1.
- The NHRP Redirect notifies Spoke 1: "You can reach destination subnet 192.168.20.0/24 directly without going through me."
- Spoke 1 sends an NHRP Resolution Request through the Hub to Spoke 2. Spoke 2 responds directly with an NHRP Resolution Reply containing its NBMA IP and authoritative subnet prefix mask.
- Spoke 1 installs an NHRP Shortcut Route (indicated by an
H(NHRP) or%marker in the routing table and CEF FIB) directly pointing to Spoke 2's NBMA IP. - All subsequent data packets flow directly between Spoke 1 and Spoke 2, bypassing the Hub entirely.
- Spoke 1 holds a default route (
Loading diagram...
3. Dynamic Routing Protocols over DMVPN: EIGRP, OSPF, and BGP
Running dynamic routing protocols over mGRE requires specific tuning based on DMVPN Phase and broadcast/multicast behavior.
+---------------------------------------------------------------------------------------------------+
| ROUTING PROTOCOL DESIGN PATTERNS ACROSS DMVPN PHASES |
+---------------------------------------------------------------------------------------------------+
| Protocol | DMVPN Phase 1 Requirement | DMVPN Phase 2 Requirement | DMVPN Phase 3 Req. |
| :---------- | :-------------------------------- | :------------------------- | :----------------- |
| **EIGRP** | `no ip split-horizon eigrp <AS>` | `no ip split-horizon` | `no ip split-horizon`|
| | `ip summary-address` allowed | `no ip next-hop-self` | `ip summary-address`|
| | | (No Summarization!) | allowed (Shortcut) |
| **OSPF** | Network: `point-to-multipoint` | Network: `broadcast` | Network: `broadcast`|
| | (Hub sets next-hop to self) | (Hub must be DR; priority 0| or `point-to-multi`|
| | | on all spokes) | (with NHRP shortcut)|
| **BGP** | eBGP or iBGP Route Reflector | BGP Route Reflector with | BGP Route Reflector|
| | (Default or summary advertised) | `next-hop-unchanged` | (Default / Summary) |
+---------------------------------------------------------------------------------------------------+
EIGRP over DMVPN
- Split-Horizon: On the Hub's
Tunnel0interface, EIGRP split-horizon must be disabled (no ip split-horizon eigrp <AS>). Because all spokes reside on the same logical IP subnet, split-horizon would otherwise prevent the Hub from readvertising routes learned from Spoke 1 out the same interface to Spoke 2. - Next-Hop Behavior:
- Phase 1 & Phase 3: Default behavior (
ip next-hop-selfenabled by default) works perfectly. In Phase 3, the NHRP shortcut mechanism overrides the routing table next-hop in the CEF forwarding path. - Phase 2: Must explicitly configure
no ip next-hop-self eigrp <AS>on the Hub so that the Hub advertises routes with the originating Spoke's tunnel IP as the next hop.
- Phase 1 & Phase 3: Default behavior (
OSPF over DMVPN
- OSPF Broadcast Network Type (
ip ospf network broadcast):- Supported in Phase 2 and Phase 3.
- A single IP subnet is used for the DMVPN tunnel. A Designated Router (DR) and Backup Designated Router (BDR) election takes place.
- Mandatory Rule: The Hub MUST be elected as the DR, and Spokes MUST NEVER become DR or BDR. Configure
ip ospf priority 255on the Hub andip ospf priority 0on all Spokes. If a spoke becomes DR, spokes cannot form full OSPF adjacencies with each other without direct full-mesh broadcast connectivity at startup.
- OSPF Point-to-Multipoint Network Type (
ip ospf network point-to-multipoint):- Treats the mGRE interface as a collection of point-to-point links. No DR/BDR election occurs.
- In Phase 1, it forces the Hub to be the next hop for all routes (ideal for Phase 1).
- In Phase 3, combined with
ip nhrp shortcut, point-to-multipoint works seamlessly because NHRP redirect/shortcut dynamically resolves direct spoke-to-spoke forwarding.
BGP over DMVPN
- BGP Dynamic Neighbors (
bgp listen range): Eliminates manualneighbor <IP> remote-asstatements on the Hub. The Hub dynamically accepts BGP peering connections from any spoke within a configured CIDR prefix. - BGP Route Reflector: The Hub is configured as a BGP Route Reflector (
neighbor <GROUP> route-reflector-client). In Phase 2, the Hub must preserve the next hop usingneighbor <GROUP> next-hop-unchanged.
4. Cisco FlexVPN Architecture & Operations
Cisco FlexVPN is Cisco's unified, next-generation VPN solution built entirely upon Internet Key Exchange version 2 (IKEv2 - RFC 7296). FlexVPN replaces legacy IKEv1, proprietary NHRP, and disparate VPN architectures (EZVPN, DMVPN, Crypto Maps) with a single modular framework.
+---------------------------------------------------------------------------------------------------+
| FLEXVPN ARCHITECTURAL BUILDING BLOCKS |
+---------------------------------------------------------------------------------------------------+
| |
| [ IKEv2 PROPOSAL & POLICY ] |
| - Negotiates encryption (AES-GCM-256), integrity (SHA-384), PRF, and DH Groups (Group 19/20/21). |
| - Native DoS protection with anti-cookie challenges and high-speed multi-threading. |
| |
| [ IKEv2 PROFILE ] |
| - Defines authentication identity (FQDN, IPv4, DN) and authentication methods. |
| - Supports Asymmetric Authentication: e.g., Pre-Shared Key (PSK) or RSA-Certificates. |
| - Binds to Virtual-Template for dynamic Virtual-Access interface instantiation. |
| |
| [ IPSEC PROFILE & TRANSFORM SET ] |
| - Defines ESP encapsulation (e.g., 'esp-gcm 256') in Transport or Tunnel Mode. |
| - Applied directly to Virtual-Template or static Virtual Tunnel Interfaces (sVTI). |
| |
| [ VIRTUAL-TEMPLATE & DYNAMIC VIRTUAL-ACCESS (dVTI) ] |
| - Hub defines a single 'interface Virtual-Template' template configuration. |
| - When a Spoke or Remote Worker authenticates, Hub clones a unique 'interface Virtual-Access<N>'|
| dedicated point-to-point interface for that session. |
| - Enables per-spoke QoS queuing, RADIUS authorization attributes, and VRF injection. |
+---------------------------------------------------------------------------------------------------+
+---------------------------------------------------------------------------------------------------+
| DMVPN VS. CISCO FLEXVPN FEATURE COMPARISON |
+---------------------------------------------------------------------------------------------------+
| Feature | Dynamic Multipoint VPN (DMVPN) | Cisco FlexVPN |
| :---------------------- | :------------------------------ | :------------------------------------ |
| **Underlying Protocol** | mGRE + NHRP + IPsec (IKEv1/v2) | Pure IKEv2 (RFC 7296) + VTI / GRE |
| **Address Resolution** | Proprietary NHRP (RFC 2332) | Standard IKEv2 Route Installation / BGP|
| **Interface Model** | Single shared `mGRE` interface | Dynamically cloned `Virtual-Access` |
| **Per-Spoke Policy** | Complex (Per-Tunnel QoS) | Native (Applied directly to dVTI) |
| **Topologies Supported**| Hub-and-Spoke, Spoke-to-Spoke | Hub-and-Spoke, Spoke-to-Spoke, |
| | | Remote Access (Client-to-Site), sVTI |
| **Authentication** | Symmetric (Same PSK/Cert type) | Asymmetric (PSK on Spoke, Cert on Hub)|
| **Routing Integration** | EIGRP, OSPF, BGP with NHRP | Dynamic BGP (Listen Range) & EIGRP |
+---------------------------------------------------------------------------------------------------+
Dynamic Routing with FlexVPN
- FlexVPN BGP Integration: The FlexVPN Hub leverages dynamic BGP peering (
bgp listen range <SUBNET> peer-group <GROUP>). When a spoke connects via IKEv2, the spoke initiates a BGP peering session across the dynamically instantiated Virtual-Access interface. The Hub acts as a BGP Route Reflector. - FlexVPN IKEv2 Route Installation: IKEv2 can automatically install routes to remote subnets using IKEv2 Configuration Payloads or Route Exchange (
set route installin the IKEv2 profile), eliminating the need for a dynamic routing protocol in small-scale hub-and-spoke deployments.
5. Production Configuration & Verification Examples
1. DMVPN Phase 3 Hub Configuration (Cisco IOS-XE)
! --- Step 1: IKEv2 Proposal, Policy, Keyring & Profile ---
crypto ikev2 proposal IKEV2_PROP
encryption aes-cbc-256
integrity sha256
group 19
!
crypto ikev2 policy IKEV2_POLICY
proposal IKEV2_PROP
!
crypto ikev2 keyring IKEV2_KEYRING
peer SPOKES
address 0.0.0.0 0.0.0.0
pre-shared-key EnterpriseKey2026!
!
crypto ikev2 profile IKEV2_PROFILE
match identity remote address 0.0.0.0 0.0.0.0
authentication remote pre-share
authentication local pre-share
keyring local IKEV2_KEYRING
!
! --- Step 2: IPsec Transform Set & Crypto Profile ---
crypto ipsec transform-set TS_AES256_SHA256 esp-aes 256 esp-sha256-hmac
mode transport
!
crypto ipsec profile IPSEC_PROFILE
set transform-set TS_AES256_SHA256
set ikev2-profile IKEV2_PROFILE
!
! --- Step 3: DMVPN Phase 3 Hub Tunnel Interface ---
interface Tunnel0
description DMVPN_PHASE3_HUB_OVERLAY
ip address 172.16.1.1 255.255.255.0
no ip redirects
ip mtu 1400
ip tcp adjust-mss 1360
ip nhrp network-id 100
ip nhrp redirect !<--- MANDATORY FOR DMVPN PHASE 3 HUB
ip nhrp map multicast dynamic
tunnel source GigabitEthernet0/0/0 !<--- Physical WAN Underlay Interface
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile IPSEC_PROFILE
!
! --- Step 4: Routing (EIGRP Named Mode) ---
router eigrp ENTERPRISE
address-family ipv4 unicast autonomous-system 65000
af-interface Tunnel0
no split-horizon
exit-af-interface
topology base
exit-af-topology
network 172.16.1.0 0.0.0.255
network 10.0.0.0 0.255.255.255
exit-address-family
2. DMVPN Phase 3 Spoke Configuration (Cisco IOS-XE)
! --- Step 1: DMVPN Phase 3 Spoke Tunnel Interface ---
interface Tunnel0
description DMVPN_PHASE3_SPOKE1_OVERLAY
ip address 172.16.1.10 255.255.255.0
no ip redirects
ip mtu 1400
ip tcp adjust-mss 1360
ip nhrp network-id 100
ip nhrp shortcut !<--- MANDATORY FOR DMVPN PHASE 3 SPOKE
ip nhrp nhs 172.16.1.1 nbma 203.0.113.1 multicast
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint !<--- mGRE on Spoke (Phase 2 & 3)
tunnel key 100
tunnel protection ipsec profile IPSEC_PROFILE
!
! --- Step 2: Routing (EIGRP Named Mode) ---
router eigrp ENTERPRISE
address-family ipv4 unicast autonomous-system 65000
topology base
exit-af-topology
network 172.16.1.0 0.0.0.255
network 192.168.10.0 0.0.0.255
exit-address-family
3. FlexVPN Hub Configuration with Dynamic Virtual-Template & BGP (Cisco IOS-XE)
! --- Step 1: IKEv2 Configuration with Virtual-Template Binding ---
crypto ikev2 profile FLEXVPN_IKEV2_PROFILE
match identity remote address 0.0.0.0 0.0.0.0
authentication local pre-share
authentication remote pre-share
keyring local IKEV2_KEYRING
virtual-template 1 !<--- Binds IKEv2 session to dynamic template
!
! --- Step 2: Virtual-Template Interface Definition ---
interface Virtual-Template1 type tunnel
ip unnumbered Loopback0
ip nhrp network-id 200
tunnel mode ipsec ipv4 !<--- Native IPsec VTI (No GRE header needed)
tunnel protection ipsec profile IPSEC_PROFILE
!
! --- Step 3: Dynamic BGP Listen Range Peering ---
router bgp 65000
bgp log-neighbor-changes
bgp listen range 172.16.2.0/24 peer-group FLEX_SPOKES
neighbor FLEX_SPOKES peer-group
neighbor FLEX_SPOKES remote-as 65000
neighbor FLEX_SPOKES route-reflector-client
neighbor FLEX_SPOKES update-source Loopback0
4. Verification and Diagnostic CLI Commands
Hub-Router# show dmvpn
Legend: Char - Description
--------
D - Dynamic, S - Static, N - NATed, L - Local, I - Incomplete
# Ent Peer NBMA Addr RM - DN Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------------- --------------- ----- -------- -----
1 198.51.100.10 172.16.1.10 UP 04:12:33 D
1 198.51.100.20 172.16.1.20 UP 02:45:11 D
Spoke1-Router# show ip nhrp
172.16.1.1/32 via 172.16.1.1
Tunnel0 created 04:15:22, never expire
Type: static, Flags: authoritative used
NBMA: 203.0.113.1
192.168.20.0/24 via 172.16.1.20
Tunnel0 created 00:08:14, expire 01:51:46
Type: dynamic, Flags: router implicit shortcut redirect
NBMA: 198.51.100.20
Spoke1-Router# show ip route nhrp
Routing Table: Global
Codes: H - NHRP, % - next hop override
H % 192.168.20.0/24 [250/1] via 172.16.1.20, 00:08:15, Tunnel0
Test Your Knowledge
A network engineer is deploying a DMVPN Phase 2 overlay network across 100 branch offices using EIGRP as the interior routing protocol. After verifying that all spokes successfully registered with the hub router's NHRP server, the engineer notices that spoke-to-spoke direct IPsec data tunnels fail to establish, and all data traffic continues to traverse the central hub. What routing configuration issue causes this behavior in DMVPN Phase 2?
A
B
C
D
Test Your Knowledge
An enterprise network architect is designing a large-scale DMVPN Phase 3 network connecting 500 remote branch spokes to a dual-hub data center cluster. Which combination of interface commands on the Hub and Spoke tunnel interfaces enables dynamic spoke-to-spoke shortcut routing while allowing the Hub to advertise only a summary or default route to all branches?
A
B
C
D
Test Your Knowledge
A network engineer needs to design a modern, standardized site-to-site and remote-access VPN architecture for an enterprise. The design must eliminate proprietary NHRP configuration overhead, provide per-spoke dynamic QoS and RADIUS policy assignment, and use dynamic point-to-point virtual interfaces cloned on-demand for every connecting peer. Which technology meets these requirements?
A
B
C
D
Test Your Knowledge
When configuring OSPFv2 over a DMVPN Phase 2 or Phase 3 network using the 'broadcast' network type ('ip ospf network broadcast') on the mGRE tunnel interface, which configuration step is mandatory to ensure reliable control plane stability?
A
B
C
D