Implement DMVPN: mGRE, NHRP & IPsec Protection Across the Phases

Overview

Dynamic Multipoint VPN (DMVPN) lets any branch reach any other branch over a tunnel nobody configured, built the moment traffic needs it, and encrypted once you add IPsec. Get the design wrong and branch-to-branch traffic hairpins through headquarters, doubling its latency and loading the hub with traffic that was never meant for it. This lesson builds a hub and two spokes, watches the hub take itself out of the path in a real capture, then encrypts the whole cloud.

Terminology: mGRE, NHRP and the NBMA Address

Three pieces make DMVPN work:

• mGRE (multipoint GRE) — GRE (Generic Routing Encapsulation) wraps one IP packet inside another; multipoint GRE does it on one tunnel interface with no fixed destination. Cisco’s DMVPN guide puts it simply: it “allows a single GRE interface to support multiple IPsec tunnels.” One mGRE interface serves every peer the router has, up to the platform’s own scaling limits.
• NHRP (Next Hop Resolution Protocol, RFC 2332) — the address book. It maps a tunnel address to the underlay address the GRE packet must be sent to.
• NBMA address — that real address. NHRP calls the underlay a non-broadcast multi-access (NBMA) network, so a peer’s underlay address is its NBMA address. On the internet that is usually a public address, but it can be private or behind NAT.

The hub runs as the next-hop server (NHS). Every spoke registers its tunnel-to-NBMA mapping with the hub, so the hub knows where every spoke lives for as long as each registration stays valid. A spoke only needs to be told where the hub is.

Design Choice: Three Phases, One Cloud

The hub runs the same mGRE tunnel in all three phases. (Classic Phase 1 spokes run point-to-point GRE to the hub instead; Phase 2 and 3 spokes run mGRE too.) What changes is what the routing protocol (EIGRP, Enhanced Interior Gateway Routing Protocol, in this lesson) advertises and what NHRP is allowed to do with it:

Enlarge figure: The three DMVPN phases compared as columns. Phase 1, spokes run point-to-point GRE and every packet between spokes crosses the hub, so the hub may summarise freely but carries all the traffic, and it is the simplest to reason about. Phase 2, spokes resolve each other and the next hop must be the far spoke: a summary cannot replace the specific spoke routes, spokes need those specific routes, and the hub keeps the next hop unchanged. Phase 3, the hub sends one summary and a redirect repairs the path: summarise to one route, the hub leaves the data path, and it scales to hierarchical hubs. A footer states that the hub's mGRE tunnel is the same in all three, and the phase is what routing and NHRP may do

Phase 3 is the one to build today. It keeps Phase 2’s direct path and drops Phase 2’s routing burden. Cisco’s NHRP shortcut-switching guide lists the payoff as letting the hub “advertise the few or one summary route to each spoke rather than all of the individual spoke routes.”

Engine Behavior: How Phase 3 Takes the Hub Out of the Path

The spoke’s routing table never changes its mind about the summary. NHRP installs a more specific route that wins the lookup instead.

Here is the sequence on the first flow from a host behind one spoke to a host behind another. The lab section below shows it in a capture:

Enlarge figure: A packet walk with three lanes: Spoke 1, which sends the first packets; the Hub, the next-hop server; and Spoke 2, which owns the destination. Step 1, data for a host behind spoke 2 goes from spoke 1 to the hub. Step 2, the hub forwards it to spoke 2 through the same tunnel it arrived on. Step 3, the hub sends an NHRP redirect, a traffic indication, back to spoke 1. Step 4, spoke 1 sends a resolution request for that host to the hub. Step 5, the hub forwards the request to the far spoke. Step 6, spoke 2 replies directly to spoke 1 with its whole prefix and its own NBMA address. Step 7, data flows directly between the spokes on the H route. A footer says the routing table still says via the hub, and the H route is what sends it direct

1. The first packets follow the summary to the hub. The sending spoke has no better route, so it sends the traffic to the hub.
2. The hub forwards them to the owning spoke and notices a hairpin. In Cisco’s words, the hub “detects that this data packet has been received on and forwarded out the same tunnel interface.”
3. The hub sends an NHRP redirect (a traffic indication) back to the sending spoke. The traffic still arrives; the redirect is advice, not a drop.
4. The spoke asks who owns the destination. It sends a resolution request for the destination host along the routed path, through the hub.
5. The hub forwards the request to the spoke that owns the prefix.
6. The owning spoke answers directly. It replies straight to the sending spoke’s NBMA address with the prefix it routes the destination by (here the branch’s whole /24), not just the one host.
7. The spoke installs an NHRP route for that prefix, and following packets to it go direct. That shortcut is cached per prefix, not per flow: a new connection to a host behind the same spoke uses the direct path at once.

Design Choice: Protecting the Cloud with IKEv2

GRE carries the traffic but encrypts nothing. tunnel protection ipsec profile wraps every GRE packet on the tunnel in ESP (Encapsulating Security Payload; with the AES transform this lesson uses, it encrypts as well as authenticates). Because the tunnel has no fixed destination, the IPsec sessions are built on demand: one to the hub when the spoke registers, and one to each spoke it resolves.

Three decisions go into the profile:

• Transport mode. GRE already provides the outer IP header that carries the tunnel, so tunnel mode only adds a second one. Cisco’s DMVPN guide requires transport mode for its NAT-transparency support, which makes it the normal choice.
• A wildcard pre-shared key. Any spoke can appear from any address, so the hub’s keyring matches peer 0.0.0.0 0.0.0.0. In production, use certificates with the peer identity checked: a single shared key across every branch means one compromised branch holds the key to all of them.
• An explicit IKEv2 proposal. On this lab’s IOSv 15.9 image, the IKEv2 smart-default proposal offers Diffie-Hellman groups 5 and 2 only (the 15M&T IKEv2 guide lists both; other releases differ). Both are legacy MODP groups (modular-exponentiation Diffie-Hellman, 1536 and 1024 bits) that no new deployment should use. Leave the default alone and your cloud is keyed with group 5. Group 19, a 256-bit elliptic-curve group, is a sound current choice.

Lab Reference

This lesson uses the SVPN lab topology. All examples reference these specific devices and IP addresses.

Topology

Enlarge figure: The lesson's lab slice. R-ISP-01 in the centre is the internet. R-HUB-01 above it at 198.51.100.10, tunnel 10.255.10.254. R-BRANCH-01 at 192.0.2.2, tunnel 10.255.10.1, with WS-BRANCH-01 at 10.20.1.10 behind it; R-BRANCH-02 at 192.0.2.6, tunnel 10.255.10.2, with WS-BRANCH-02 at 10.20.2.10 behind it. Solid lines are the underlay through R-ISP-01; dashed lines are the DMVPN overlay from the hub to each spoke. Spoke-to-spoke tunnels are built on demand and not drawn.

The hub sits beside the HQ firewalls, not behind them. That makes it a dedicated VPN concentrator: the overlay comes up without changing a single firewall rule, and no other lesson’s traffic moves. The underlay is deliberately dumb. R-ISP-01 knows only the routable underlay addresses (documentation ranges standing in for the internet), so any private traffic that crosses the lab is crossing a tunnel.

Configuration

Scenario 1: Put Both Branches and HQ on One DMVPN Cloud

The two branches need to reach HQ and each other, and a third branch next quarter must not mean editing the other two.

Step 1 — build the hub. On R-HUB-01:

! Step 1a: the multipoint tunnel, sourced from the outside interface
interface Tunnel0
 description DMVPN hub - NHRP next-hop server
 ip address 10.255.10.254 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360

! Step 1b: NHRP — the address book, and the hub's two Phase 3 duties
 ip nhrp network-id 10
 ip nhrp map multicast dynamic
 ip nhrp redirect
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 10

! Step 1c: routing over the cloud — one summary down the tunnel
router eigrp 100
 network 10.255.10.0 0.0.0.255
 network 10.10.10.0 0.0.0.255
interface Tunnel0
 ip summary-address eigrp 100 10.0.0.0 255.0.0.0

ip nhrp map multicast dynamic adds each spoke to the multicast list as it registers, which is what lets EIGRP hellos reach the spokes at all. On this lab’s IOSv 15.9(3)M12 image it is also on by default: show running-config all lists it, and the running config omits it. Type it anyway; Cisco’s DMVPN examples configure it explicitly, and your hub’s software may not share this image’s default.

Step 2 — build a spoke. On R-BRANCH-01 (on R-BRANCH-02, use .2 and 10.20.2.0):

! Step 2a: same tunnel shape, the spoke's own address
interface Tunnel0
 description DMVPN spoke - registers with R-HUB-01
 ip address 10.255.10.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360

! Step 2b: where the hub is, and permission to shortcut
 ip nhrp network-id 10
 ip nhrp nhs 10.255.10.254 nbma 198.51.100.10 multicast
 ip nhrp shortcut
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 10

! Step 2c: advertise the branch LAN
router eigrp 100
 network 10.255.10.0 0.0.0.255
 network 10.20.1.0 0.0.0.255

ip nhrp nhs ... nbma ... multicast does three jobs on one line. It names the hub’s tunnel address, maps it to the hub’s NBMA address, and sends multicast (the EIGRP hellos) to it.

Type ip nhrp shortcut and then look for it: it is not there. On this IOSv image it is on by default, so the running configuration hides it, exactly as the hub hides ip nhrp map multicast dynamic. The saved end-state configurations at the end of this lesson were taken from these routers and omit both lines. To confirm a default is in force, read show running-config all, not show running-config.

ip mtu 1400 and ip tcp adjust-mss 1360 in Step 1a and 2a leave room for the headers the tunnel adds. ip mtu sets the IP MTU (maximum transmission unit) of the tunnel interface: the largest IP packet it forwards without fragmenting. ip tcp adjust-mss lowers the MSS (maximum segment size) option in TCP SYN and SYN-ACK packets crossing the interface whenever the advertised value is higher, so the two hosts agree on segments small enough to fit once the tunnel headers are added.

Verify: The hub sees both spokes register

R-HUB-01# show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
	N - NATed, L - Local, X - No Socket
	T1 - Route Installed, T2 - Nexthop-override
	C - CTS Capable, I2 - Temporary
	# Ent --> Number of NHRP entries with same NBMA peer
	NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
	UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details 
Type:Hub, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.0.2.2           10.255.10.1    UP 00:01:25     D
     1 192.0.2.6           10.255.10.2    UP 00:00:35     D

Both spokes are D (dynamic): they registered themselves, and the hub has no configuration for either. Adding a third branch touches only the third branch.

Registrations are refreshed, not permanent. Cisco’s NHRP guide says a spoke re-registers every one-third of the NHRP holdtime unless ip nhrp registration timeout sets its own interval. On this IOSv image, show running-config all lists ip nhrp holdtime 600 and ip nhrp registration timeout 200, and the capture below shows the refresh arriving 200 seconds apart.

Verify: The spoke knows only the hub, and only the summary

R-BRANCH-01# show ip route eigrp | begin Gateway
Gateway of last resort is 192.0.2.1 to network 0.0.0.0

      10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
D        10.0.0.0/8 [90/27008000] via 10.255.10.254, 00:01:12, Tunnel0

One route to all of 10.0.0.0/8, via the hub. Branch 2’s LAN is nowhere in this table, which is the Phase 3 bargain.

Verify: The first trace uses the hub, the second does not

From WS-BRANCH-01:

WS-BRANCH-01:~$ traceroute -n -w 2 10.20.2.10
traceroute to 10.20.2.10 (10.20.2.10), 30 hops max, 46 byte packets
 1  10.20.1.1  2.155 ms  1.927 ms  1.936 ms
 2  10.255.10.254  7.003 ms  4.581 ms  4.480 ms
 3  10.255.10.2  12.901 ms  6.759 ms  5.583 ms
 4  10.20.2.10  4.805 ms  4.594 ms  4.713 ms
WS-BRANCH-01:~$ traceroute -n -w 2 10.20.2.10
traceroute to 10.20.2.10 (10.20.2.10), 30 hops max, 46 byte packets
 1  10.20.1.1  2.845 ms  2.665 ms  3.214 ms
 2  10.255.10.2  6.927 ms  4.805 ms  7.162 ms
 3  10.20.2.10  5.815 ms  6.049 ms  4.244 ms

Four hops became three with nothing reconfigured. The hub (10.255.10.254) is gone from the second trace. Here is why, on R-BRANCH-01:

R-BRANCH-01# show ip route | begin Gateway
Gateway of last resort is 192.0.2.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.0.2.1
      10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
D        10.0.0.0/8 [90/27008000] via 10.255.10.254, 00:14:20, Tunnel0
C        10.20.1.0/24 is directly connected, GigabitEthernet0/1
L        10.20.1.1/32 is directly connected, GigabitEthernet0/1
H        10.20.2.0/24 [250/255] via 10.255.10.2, 00:01:50, Tunnel0
C        10.255.10.0/24 is directly connected, Tunnel0
L        10.255.10.1/32 is directly connected, Tunnel0
H        10.255.10.2/32 is directly connected, 00:01:50, Tunnel0

The EIGRP summary is unchanged. Two H (NHRP) routes appeared beside it, and 10.20.2.0/24 is more specific than 10.0.0.0/8, so it wins. That is Phase 3 in one table. show dmvpn agrees, now listing R-BRANCH-02 as a dynamic peer with attribute DT1 (dynamic, route installed).

The reverse direction resolves too (packets 28 and 29): R-BRANCH-02’s replies hairpinned through the hub once, and it learned the path back to branch 1 the same way.

Scenario 2: Encrypt the Cloud Without Touching the Routing

Everything in Scenario 1 crossed the internet in clear GRE. Security wants it encrypted, with no change to routing and no outage longer than the cut-over itself.

Enlarge figure: Three packet strips. Scenario 1, clear GRE: an IP header from spoke to hub, GRE, then the inner IP header from LAN to LAN and the data. Transport mode, as this lesson configures it: the same outer IP header, then ESP, then GRE, the inner IP header and the data. Tunnel mode: the outer IP header, ESP, then a second IP header from spoke to hub again, then GRE, the inner header and the data; the repeated header is marked. ESP protects everything to its right

Transport mode inserts ESP and changes nothing else about the packet Scenario 1 already sent. Tunnel mode would repeat the spoke and hub addresses a second time inside ESP, 20 bytes per packet that carry nothing the outer header does not.

Step 3 — the same crypto block on all three routers:

! Step 3a: the proposal — replace the smart default's DH groups 5 and 2
crypto ikev2 proposal PROP-DMVPN
 encryption aes-cbc-256
 integrity sha256
 group 19
crypto ikev2 policy POL-DMVPN
 proposal PROP-DMVPN

! Step 3b: who to trust — any peer, one key
crypto ikev2 keyring KR-DMVPN
 peer ANY-SPOKE
  address 0.0.0.0 0.0.0.0
  pre-shared-key SVPN-lab-DMVPN-psk
crypto ikev2 profile IKEV2-DMVPN
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-DMVPN

! Step 3c: what to encrypt with, and where to apply it
crypto ipsec transform-set TS-DMVPN esp-aes 256 esp-sha256-hmac
 mode transport
crypto ipsec profile IPSEC-DMVPN
 set transform-set TS-DMVPN
 set ikev2-profile IKEV2-DMVPN
interface Tunnel0
 tunnel protection ipsec profile IPSEC-DMVPN

Apply it hub first, then each spoke. The moment the hub is protected, an unprotected spoke’s GRE stops being accepted:

*Sep 26 02:01:04.069: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /198.51.100.10, src_addr= 192.0.2.6, prot= 47

prot= 47 is GRE: R-BRANCH-02 is still sending clear tunnels, and the hub now insists on ESP. On the other spoke, EIGRP says the same thing its own way:

*Sep 26 02:01:16.531: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.255.10.254 (Tunnel0) is down: holding time expired
*Sep 26 02:01:44.230: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.255.10.254 (Tunnel0) is up: new adjacency

The outage per spoke runs from “hub protected” to “that spoke protected”, so do all three in one change window.

Verify: Two IKEv2 SAs on a spoke, one of them to the other spoke

After a spoke-to-spoke ping:

R-BRANCH-01# show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA 

Tunnel-id Local                 Remote                fvrf/ivrf            Status 
2         192.0.2.2/500         192.0.2.6/500         none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/12 sec

Tunnel-id Local                 Remote                fvrf/ivrf            Status 
1         192.0.2.2/500         198.51.100.10/500     none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/69 sec

One SA to the hub, built when the spoke’s first registration needed a protected path, and one straight to 192.0.2.6, built on demand when NHRP resolved branch 2. Both read DH Grp:19. Before Step 3a they read DH Grp:5, the smart default, which is the reason Step 3a exists.

Verify: Only GRE is protected, and it is counted

R-BRANCH-01# show crypto session
Crypto session current status

Interface: Tunnel0
Profile: IKEV2-DMVPN
Session status: UP-ACTIVE     
Peer: 198.51.100.10 port 500 
  Session ID: 1  
  IKEv2 SA: local 192.0.2.2/500 remote 198.51.100.10/500 Active 
  IPSEC FLOW: permit 47 host 192.0.2.2 host 198.51.100.10 
        Active SAs: 2, origin: crypto map

Interface: Tunnel0
Profile: IKEV2-DMVPN
Session status: UP-ACTIVE     
Peer: 192.0.2.6 port 500 
  Session ID: 3  
  IKEv2 SA: local 192.0.2.2/500 remote 192.0.2.6/500 Active 
  IPSEC FLOW: permit 47 host 192.0.2.2 host 192.0.2.6 
        Active SAs: 2, origin: crypto map

permit 47 again: the IPsec flow is GRE between two NBMA addresses, nothing else. IPsec here protects the GRE packet, and the GRE packet carries the user and routing traffic.

On its own, permit 47 says GRE over IPsec, not DMVPN: a point-to-point GRE tunnel with tunnel protection shows the same flow. What makes it DMVPN for objective 4.3 is that line together with tunnel mode gre multipoint and the NHRP commands on the same tunnel, or a show dmvpn with dynamic peers. By contrast, a policy-based crypto map usually shows selectors for the protected subnets, and an SVTI (static virtual tunnel interface) often shows a broad permit ip any any.

Troubleshooting

Symptom: A spoke never appears in the hub’s show dmvpn.

1. show ip nhrp nhs on the spoke. (Should show the hub with RE: R, responding, and E, expecting replies.) If it shows only E, requests go out and nothing comes back.
2. Compare tunnel key on both ends. (Should match.) If not: the hub silently ignores the spoke, exactly as packets 1–4 of the registration capture show. Fix the key. Keep ip nhrp network-id identical across the cloud as well; Cisco’s NHRP guide says all stations in one NBMA network should share it.
3. ping 198.51.100.10 from the spoke. (Should succeed.) If not: the underlay is broken and no overlay setting will help.

Symptom: Spoke-to-spoke traffic works but always crosses the hub.

1. show ip route on the spoke. (Should show an H route to the far branch after the first packets.) If only the summary is there, no shortcut was installed.
2. show running-config interface Tunnel0 | include redirect on the hub. (Should show ip nhrp redirect.) If not: the hub never tells the spoke. Add it.
3. show running-config all | include nhrp shortcut on the spoke. (Should show ip nhrp shortcut.) If not: the spoke ignores redirects. Add it.

Symptom: After adding protection, spokes flap and the hub logs %CRYPTO-4-RECVD_PKT_NOT_IPSEC.

1. Read src_addr in the log. (It names the spoke that is still unprotected.) Protect it.
2. show crypto ikev2 sa on that spoke. (Should show READY to the hub.) If it is missing, compare the keyring, the profile’s match identity and the proposal. debug crypto ikev2 names the failing payload. Run it on one spoke only; on a busy hub it can flood the console.

🎥 [Video: the two traceroutes; mGRE, NHRP and the NHS; the three phases on one board; building the hub and a spoke and reading show dmvpn; the Phase 3 capture replayed packet by packet; tunnel protection applied hub first, the refused GRE, the IKEv2 SAs, and the DH group fixed. Matches video.script_outline. Runtime: ~10 minutes]

Up next: Implement Site-to-Site FlexVPN with Local AAA Authorization moves the same two branches onto FlexVPN, where the hub hands each spoke its routes through IKEv2 itself, with no routing protocol on the tunnel at all.