Skip to content
Log in Sign up My account

2.3 DMVPN Building Blocks: mGRE, NHRP and IPsec

Blueprint 2.3: Configure and verify DMVPN (single hub)

  • 2.3.a GRE/mGRE
  • 2.3.b NHRP
  • 2.3.c IPsec
  • 2.3.d Dynamic neighbor
  • 2.3.e Spoke-to-spoke

This page covers the parts every DMVPN is built from (2.3.a to 2.3.c) and builds a working single-hub cloud. DMVPN Phases and Routing covers phases 1 to 3, spoke-to-spoke tunnels, dynamic neighbors and the routing protocol settings each phase needs (2.3.d and 2.3.e).

This is a configure and verify objective on a troubleshooting exam. Expect a full DMVPN sim or exhibit questions with show dmvpn, show ip nhrp and tunnel configurations where one line is wrong. You need the syntax from memory, and you need to know which show output proves which layer is working.

What DMVPN solves

A company with one head office and 200 branches wants every branch to reach the head office, and branches to reach each other, over the Internet, encrypted. With classic point-to-point GRE over IPsec, the hub needs 200 tunnel interfaces and 200 crypto peers, and every new branch means a configuration change on the hub. Full mesh needs about 20,000 tunnels.

Dynamic Multipoint VPN (DMVPN) fixes that with three ingredients:

Ingredient Role
mGRE One multipoint tunnel interface on each router, for all peers
NHRP A directory that maps tunnel (overlay) addresses to public (NBMA, underlay) addresses, so the router knows where to send each GRE packet
IPsec profile Encrypts the GRE packets to whichever peer they go to, without per-peer crypto maps

The hub configuration is the same whether it has 2 spokes or 200. Spokes register themselves dynamically, and spokes can build direct tunnels to each other on demand.

graph TB
  subgraph Overlay ["Overlay: Tunnel0 172.16.0.0/24"]
    H["HUB (NHS)<br/>Tu0 172.16.0.1"]
    S1["SPOKE1 (NHC)<br/>Tu0 172.16.0.2"]
    S2["SPOKE2 (NHC)<br/>Tu0 172.16.0.3"]
  end
  H -- "static tunnel" --- S1
  H -- "static tunnel" --- S2
  S1 -. "dynamic spoke-to-spoke" .- S2
  NET(("Internet<br/>NBMA underlay"))
  H -- "NBMA 203.0.113.1" --- NET
  S1 -- "NBMA 198.51.100.1" --- NET
  S2 -- "NBMA 198.51.100.5" --- NET

Vocabulary: the NBMA address is the physical, public address used as the GRE source and destination (the underlay). The tunnel address is the overlay address on the tunnel interface. The hub is the NHS (next hop server); spokes are NHCs (next hop clients).

GRE and mGRE

GRE (IP protocol 47) wraps any packet in a new IP header plus a 4-byte GRE header: 24 bytes of overhead, or 28 bytes when a tunnel key is used. GRE can carry multicast, which is why routing protocols run over it, but it has no encryption.

Point-to-point GRE Multipoint GRE (mGRE)
Mode tunnel mode gre ip (default) tunnel mode gre multipoint
Destination tunnel destination <NBMA> None. NHRP supplies the destination per packet.
Peers per interface One Many
Multicast Sent to the one destination Replicated to the NBMA addresses in the NHRP multicast table
Used in DMVPN on Phase 1 spokes Hubs (all phases), spokes in phases 2 and 3

Settings that must be consistent across the whole cloud:

  • tunnel key (if used on one router, it must be on all, with the same value). The key is carried in every GRE packet; a router drops GRE packets with a different key or a missing key.
  • ip nhrp authentication string (if used).
  • The tunnel subnet.

MTU

GRE plus IPsec adds 50 to 80 bytes or more depending on the transform. The standard Cisco DMVPN settings, which you should recognise in any exhibit, are:

interface Tunnel0
 ip mtu 1400
 ip tcp adjust-mss 1360

ip mtu 1400 makes the router fragment or reject (with ICMP) before encapsulation instead of fragmenting the encrypted packet. ip tcp adjust-mss 1360 rewrites the MSS in TCP SYNs so hosts never send segments that need fragmenting (1400 minus 20 bytes of IP header and 20 bytes of TCP header).

Recursive routing

A tunnel's NBMA destination must always be reached through the underlay, never through the tunnel itself. If a router learns a peer's NBMA address (or a more specific covering route) through the routing protocol over the tunnel, the route to the tunnel endpoint points into the tunnel itself. On a point-to-point GRE tunnel, such as a phase 1 spoke, IOS logs %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing and the tunnel flaps. On mGRE the symptom is that the affected peers keep dropping and re-registering.

Exam trap

A DMVPN that comes up, then goes down and up every few seconds with RECURDOWN messages is a recursive routing problem, not an IPsec or NHRP problem. The fix is to keep the underlay prefixes out of the overlay routing protocol (tighter network statements, a distribute list, or a front-door VRF for the underlay interface).

NHRP

NHRP (RFC 2332) is the address resolution protocol of DMVPN. It plays the role ARP plays on Ethernet: given a tunnel next-hop address, find the NBMA address to put in the outer IP header.

Message types

Message From and to Purpose
Registration request / reply Spoke to hub Spoke tells the hub "my tunnel address 172.16.0.2 is at NBMA 198.51.100.1". The hub stores a dynamic mapping.
Resolution request / reply Spoke to spoke, through the hub "What NBMA address has tunnel address 172.16.0.3 (or the network 10.3.3.0/24)?" The answer comes back directly from the owning spoke.
Redirect (traffic indication) Hub to spoke Phase 3 only: "you just sent me traffic that should go directly to another spoke".
Purge Any Removes a stale mapping.
Error Any Reports a problem, such as an authentication failure.

Registration is what brings a spoke into the cloud. The spoke knows the hub's tunnel and NBMA addresses from its configuration (a static mapping). It sends a registration request to the hub, and the hub learns the spoke's NBMA address from it (a dynamic mapping). Spokes re-register periodically, by default every one-third of the NHRP hold time. The hold time defaults to 7200 seconds; Cisco design guides use 300 to 600 seconds so stale mappings age out faster.

Because the hub learns spokes from their registrations, adding a spoke never changes the hub configuration. That is the "dynamic" in DMVPN.

The NHRP commands

Command Where What it does
ip nhrp network-id 1 All Enables NHRP on the interface. Locally significant: it does not need to match between routers. On one router it groups tunnel interfaces into the same NHRP domain.
ip nhrp authentication KEY All Clear-text string (up to 8 characters) carried in NHRP packets. Must match.
ip nhrp holdtime 300 All How long others keep the mapping this router advertises
ip nhrp map multicast dynamic Hub Add each registering spoke to the multicast replication list, so routing protocol hellos reach the spokes
ip nhrp nhs 172.16.0.1 nbma 203.0.113.1 multicast Spokes Static mapping for the hub, hub as NHS, and hub as multicast destination, in one line
ip nhrp redirect Hub Phase 3: send redirects
ip nhrp shortcut Spokes Phase 3: act on redirects by installing shortcut routes 
interface Tunnel0
 ip nhrp nhs 172.16.0.1 nbma 203.0.113.1 multicast


interface Tunnel0
 ip nhrp map 172.16.0.1 203.0.113.1
 ip nhrp map multicast 203.0.113.1
 ip nhrp nhs 172.16.0.1
Both forms do the same thing: map the hub's tunnel address to its NBMA address, send multicast to the hub, and use the hub as NHS. The classic form is common in older exhibits.

Exam trap

In ip nhrp nhs, the first address is the hub's tunnel address, and the NBMA address follows the nbma keyword. In the classic ip nhrp map command, the order is the same: tunnel address first, NBMA address second. An exhibit that swaps them is a fault. An exhibit where only the ip nhrp network-id values differ between hub and spoke is not a fault.

IPsec protection

GRE and NHRP give connectivity; IPsec gives confidentiality and integrity. DMVPN uses an IPsec profile instead of a crypto map. The profile is applied to the tunnel interface and automatically protects the GRE traffic to whatever NBMA peer each packet is sent to. Peers are never listed.

crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key DMVPNkey address 0.0.0.0
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport
!
crypto ipsec profile DMVPN-PROF
 set transform-set TS
!
interface Tunnel0
 tunnel protection ipsec profile DMVPN-PROF

crypto ikev2 keyring DMVPN-KR
 peer ANY
  address 0.0.0.0 0.0.0.0
  pre-shared-key DMVPNkey
!
crypto ikev2 profile DMVPN-IKEV2
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local DMVPN-KR
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport
!
crypto ipsec profile DMVPN-PROF
 set transform-set TS
 set ikev2-profile DMVPN-IKEV2
!
interface Tunnel0
 tunnel protection ipsec profile DMVPN-PROF

Key points:

  • The pre-shared key uses a wildcard address (0.0.0.0) because spokes have dynamic or unknown public addresses, and spoke-to-spoke tunnels need the key too.
  • Transport mode is recommended. GRE already adds a new outer IP header, so tunnel mode would add a second one for nothing (20 extra bytes). Transport mode also works when a spoke is behind NAT.
  • The ISAKMP policy number is a local priority; what must match is the content (encryption, hash, authentication, DH group). Keys are case sensitive.
  • The underlay must allow UDP 500 (IKE), UDP 4500 (NAT traversal) and IP protocol 50 (ESP) between the hub and spokes and between spokes, because spoke-to-spoke tunnels are encrypted too.

Order of operations when a spoke starts: the first GRE packet the spoke tries to send is the NHRP registration. That triggers IKE with the hub. Only after the IPsec SAs are up does the registration get through, then the routing protocol forms a neighbor. So if IPsec fails, NHRP and routing fail with it.

Exam trap

If show dmvpn on a spoke shows the hub stuck in state NHRP or IKE and show crypto isakmp sa shows MM_NO_STATE, look at IKE first: UDP 500 blocked, no matching ISAKMP policy, or no route to the hub's NBMA address. MM_KEY_EXCH that never moves on points to a pre-shared key mismatch. QM_IDLE means IKE phase 1 is healthy.

Verification

R1# 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
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 198.51.100.1         172.16.0.2    UP 00:12:31     D
     1 198.51.100.5         172.16.0.3    UP 00:12:28     D
State Meaning
UP Registration done (spoke view: the hub answered; hub view: the spoke registered)
NHRP Waiting on NHRP: registration sent, no reply
IKE IPsec is still negotiating
IPsec IKE done, IPsec SAs not yet up 
R1# show ip nhrp
172.16.0.2/32 via 172.16.0.2
   Tunnel0 created 00:12:33, expire 00:04:27
   Type: dynamic, Flags: registered used nhop
   NBMA address: 198.51.100.1
172.16.0.3/32 via 172.16.0.3
   Tunnel0 created 00:12:30, expire 00:04:30
   Type: dynamic, Flags: registered used nhop
   NBMA address: 198.51.100.5

R2# show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel0:
172.16.0.1  RE NBMA Address: 203.0.113.1 priority = 0 cluster = 0  req-sent 41  req-failed 0  repl-recv 41

RE means the hub is responding and the spoke expects replies. A growing req-failed count with no R flag means registrations are not answered.

R1# show ip nhrp multicast
  I/F     NBMA address
Tunnel0    198.51.100.1     Flags: dynamic          (Enabled)
Tunnel0    198.51.100.5     Flags: dynamic          (Enabled)

An empty multicast table on the hub means ip nhrp map multicast dynamic is missing, and routing protocol hellos will not reach the spokes.

R2# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
203.0.113.1     198.51.100.1    QM_IDLE           1001 ACTIVE

R2# show crypto ipsec sa | include pkts encaps|pkts decaps
    #pkts encaps: 512, #pkts encrypt: 512, #pkts digest: 512
    #pkts decaps: 508, #pkts decrypt: 508, #pkts verify: 508

Encaps rising while decaps stays at zero means traffic leaves but nothing returns protected: look at the far end or at something dropping ESP in the path.

Other useful commands: show crypto session (one-line summary per peer), show dmvpn detail, show ip nhrp traffic (counts of each NHRP message type), debug nhrp and debug crypto isakmp.

Lab: single-hub DMVPN with IPsec and EIGRP

This is the module lab. You build it here and convert it between phases on the next page.

Topology: four IOSv routers. R4 plays the Internet and only has the NBMA subnets. Each LAN is a loopback.

graph TB
  R4["R4 ISP"]
  R1["R1 HUB<br/>Tu0 172.16.0.1<br/>Lo1 10.1.1.1/24"] -- "Gi0/0 .1  203.0.113.0/30  .2 Gi0/0" --- R4
  R2["R2 SPOKE1<br/>Tu0 172.16.0.2<br/>Lo1 10.2.2.1/24"] -- "Gi0/0 .1  198.51.100.0/30  .2 Gi0/1" --- R4
  R3["R3 SPOKE2<br/>Tu0 172.16.0.3<br/>Lo1 10.3.3.1/24"] -- "Gi0/0 .5  198.51.100.4/30  .6 Gi0/2" --- R4
  R2 -. "dynamic" .- R3

Steps

  1. Address the physical links and loopbacks. On R1, R2 and R3 add a default route to R4 (ip route 0.0.0.0 0.0.0.0 203.0.113.2 on R1, and the matching .2 or .6 next hop on the spokes). Confirm R2 can ping 203.0.113.1 and 198.51.100.5.
  2. Add the IKEv1 crypto configuration from the tab above, identical on all three routers.

  3. Configure the hub tunnel on R1:

    interface Tunnel0
 bandwidth 10000
 ip address 172.16.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp authentication NHRPkey
 ip nhrp network-id 1
 ip nhrp holdtime 300
 ip nhrp map multicast dynamic
 ip nhrp redirect
 no ip split-horizon eigrp 100
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-PROF

  4. Configure each spoke tunnel. On R2 (R3 is the same with 172.16.0.3):

    interface Tunnel0
 bandwidth 10000
 ip address 172.16.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp authentication NHRPkey
 ip nhrp network-id 1
 ip nhrp holdtime 300
 ip nhrp nhs 172.16.0.1 nbma 203.0.113.1 multicast
 ip nhrp shortcut
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-PROF

  5. Run EIGRP AS 100 on the tunnel and LAN only. On every router:

    router eigrp 100
 network 172.16.0.0 0.0.0.255
 network 10.0.0.0 0.255.255.255

    The network statements deliberately leave out 203.0.113.0/30 and 198.51.100.0/24, so the NBMA addresses are never learned over the tunnel (no recursive routing).

  6. Verify, in this order:

    • show crypto isakmp sa on R2: QM_IDLE toward 203.0.113.1.
    • show dmvpn on R1: both spokes UP with attribute D.
    • show ip nhrp multicast on R1: both spoke NBMA addresses.
    • show ip eigrp neighbors on R1: two neighbors on Tu0.
    • show ip route eigrp on R2: 10.1.1.0/24 and 10.3.3.0/24 via Tunnel0.
  7. From R2, ping 10.3.3.1 source Loopback1, then run show dmvpn on R2 again. A second, dynamic entry for 198.51.100.5 should appear: a spoke-to-spoke tunnel. show crypto isakmp sa on R2 now lists two peers.
  8. Break it. One at a time, and fix each before the next:
    • Change the tunnel key on R3 to 101. R3 stays in state NHRP.
    • Remove ip nhrp map multicast dynamic on R1, then clear ip nhrp on R1. Registrations still succeed, but EIGRP neighbors on R1 reset with "retry limit exceeded".
    • Change the pre-shared key on R3. show crypto isakmp sa on R3 never reaches QM_IDLE.
    • Add network 198.51.100.0 0.0.0.3 to EIGRP on R2. R1 now learns R2's NBMA subnet over Tunnel0, and because a /30 is more specific than the default route, R1's path to R2's NBMA address points into the tunnel. Watch the EIGRP neighbor and the DMVPN entry for R2 flap on R1, then remove the statement.

Quick check

Why does the hub need ip nhrp map multicast dynamic but the spokes do not?

The hub must send routing protocol multicast (EIGRP hellos and updates) to every spoke, and it only knows the spokes from their registrations. The command adds each registered spoke to the hub's multicast replication list. Spokes only send multicast to the hub, which the multicast keyword on ip nhrp nhs (or ip nhrp map multicast <hub NBMA>) already covers.

Hub and spoke have different ip nhrp network-id values but the same tunnel key and NHRP authentication. Does the spoke register?

Yes. The network ID is locally significant. The tunnel key and authentication string must match.

Why is IPsec transport mode preferred for DMVPN?

GRE already provides an outer IP header with the NBMA addresses. Tunnel mode would add another 20-byte IP header with the same addresses. Transport mode protects the GRE packet with less overhead and works through NAT.

References