How to Troubleshoot Cisco’s Dynamic Multipoint VPN (DMVPN)

Dynamic Multipoint Virtual Private Network (DMVPN) is a network solution for those that have many sites that need access to either a hub site or to each other. It was designed by Cisco to help reduce the complexities in configuring and supporting a full mesh of VPNs between sites. There are other vendors that now support DMVPN, but Cisco is where it started.

Benefits of using DMVPN

The dynamic component of DMVPN is that a portion of the VPNs may not have to be pre-configured on all end points of the VPNs. DMVPN allows for the possibility of dynamic spoke-to-spoke communication, once the spokes have made contact with the hub or hubs.

It was intended to be used in a hub-and-spoke configuration (with the possibility of redundant hubs). DMVPN is based on RFC-based solutions: Generic Routing Encapsulation (GRE RFC 1701), Next Hop Resolution Protocol (NHRP RFC 2332) and Internet Protocol Security (IPSec, there are multiple RFCs and standards).

The main idea is to reduce the configuration on the hub(s) router and push some of the burden onto the spoke routers. Using the NHRP to register the spokes to the hub, the spoke can then use the hub as a resolution server to be able to build dynamic tunnels to other spokes.

What if it doesn’t work?

There are several moving parts here to look at: base configuration of the tunnel interfaces (and the basic connectivity), the registration of the spokes to the hub(s), and IPSec.

First off, the tunnel interfaces have to be configured with a source interface or address to create the tunnel, known as the public address relative to DMVPN. The addressing can be either IPv4 or IPv6, but the addressing for the source of the tunnel interfaces must be reachable by the other routers. Whether it’s spoke to hub or hub to spoke, using a ping or traceroute is the best way to verify connectivity.

The configuration may require IPSec, but try the tunnels without it. Ping the tunnel interface address, known as the private address. If the tunnels work without IPSec but don’t work with it, jump to troubleshooting IPSec. If the tunnels aren’t able to pass traffic without IPSec, then start looking at the basic configuration of the tunnel and the next hop resolution protocol.

The configuration of the hub is minimal, typically, relative to NHRP; most is done on the spoke routers. Make sure that mapping states are correct—ip(v6) nhrp map “private-address” “public-address.” Also, make sure the next hop server command is pointing to the public address of the hub—ip(v6) nhrp hns “public-address.”

interface Tunnel123
 ip address
 ip nhrp map
 ip nhrp map multicast
 ip nhrp network-id 1
 ip nhrp nhs
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

In this example, the address space is the private addressing and 10.1.1.x is the public.

The router will let you misconfigure these commands with the incorrect addresses with no errors. You can use the show ip nhrp nhs detail to check if the spoke-to-server request is successful.

R1#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel123:  RE priority = 0 cluster = 0  req-sent 2  req-failed 0  repl-recv 2 (00:03:13 ago)

On the next hop server, you can verify that the registration was successful with the show ip nhrp command.

R2#show ip nhrp via
   Tunnel123 created 00:04:30, expire 01:55:29
   Type: dynamic, Flags: unique registered
   NBMA address: via
   Tunnel123 created 00:04:30, expire 01:55:29
   Type: dynamic, Flags: unique registered
   NBMA address:

If the intent is to allow the spoke to dynamically form tunnels, but they aren’t formed, check to ensure the shortcut forwarding is enabled on the spokes in question. The interface command ip nhrp shortcut is needed to enable this shortcut forwarding. Try doing a traceroute from one spoke to another and see if the hub shows up as an intermediate hop. If so, then shortcut forwarding is not enabled.

Another consideration with DMVPN is the registration process. This process is initiated by the spokes, not the hub. If the hub router reloads or if the tunnel interface goes down and comes back up, you may have to shut down or “no shutdown” the spoke routers interfaces. This issue has been resolved in 15.2 code and anything more recent.

If communication works without IPSec, but doesn’t with IPSec configured, it’s time to troubleshoot the IPSec configuration. The policies for phase 1 (key exchange) and phase 2 (transformation of the data) have to be the same between the hub router(s) and spokes. There can be different policies for specific spokes, but that would require different tunnel interfaces.  Check the key exchange by using the show crypto isakmp policy command on the routers in question.

R1#sh crypto isakmp policy

Global IKE policy
Protection suite of priority 10
        encryption algorithm:   Three key triple DES
        hash algorithm:         Secure Hash Standard 2 (256 bit)
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit

To verify that phase 1 is successful, use the show crypto isakmp sa command.

R1#sh crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption

C-id  Local           Remote          I-VRF  Status Encr Hash   Auth DH Lifetime Cap.

1002               ACTIVE 3des sha256 psk  2  23:58:43
       Engine-id:Conn-id =  SW:2

1001               ACTIVE 3des sha256 psk  2  23:58:42
       Engine-id:Conn-id =  SW:1


If it looks like phase 1, check that the transform sets are consistent by comparing the output of the show crypto ipsec transform-set command on the hub and spoke routers.

R1#show crypto ipsec transform-set
Transform set default: { esp-aes esp-sha-hmac  }
   will negotiate = { Transport,  },

Transform set MyTS: { ah-sha256-hmac  }
   will negotiate = { Tunnel,  },
   { esp-3des  }
   will negotiate = { Tunnel,  },

To verify that the IPSec negotiation was successful, use the show crypto ipsec sa command. This can show you the packets that are being sent and whether they’re encrypted or not.

R1#sh crypto ipsec sa

interface: Tunnel123
    Crypto map tag: Tunnel123-head-0, local addr

protected vrf: (none)
   local  ident (addr/mask/prot/port): (
   remote ident (addr/mask/prot/port): (
   current_peer port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 55, #pkts encrypt: 55, #pkts digest: 55
    #pkts decaps: 54, #pkts decrypt: 54, #pkts verify: 54
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.:, remote crypto endpt.:
     path mtu 1500, ip mtu 1500, ip mtu idb (none)
     current outbound spi: 0x51F10868(1374750824)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x59A9D043(1504301123)
- output omitted -

For troubleshooting DMVPN issues, the best thing is to break it down to its components—basic connectivity, basic tunnel function and then security.
For more DMVPN troubleshooting options, visit

Related Courses
CIERS1 – Cisco Expert-Level Training for CCIE Routing and Switching v5.0
CIERS2 – Cisco Expert-Level Training for CCIE Routing and Switching Advanced Workshop 2 v5.0

In this article

Join the Conversation