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 192.168.123.1 255.255.255.0 ip nhrp map 192.168.123.2 10.1.1.2 ip nhrp map multicast 10.1.1.2 ip nhrp network-id 1 ip nhrp nhs 192.168.123.2 tunnel source FastEthernet0/0 tunnel mode gre multipoint In this example, the 192.168.123.0/24 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: 192.168.123.2 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 192.168.123.1/32 via 192.168.123.1 Tunnel123 created 00:04:30, expire 01:55:29 Type: dynamic, Flags: unique registered NBMA address: 10.1.1.1 192.168.123.3/32 via 192.168.123.3 Tunnel123 created 00:04:30, expire 01:55:29 Type: dynamic, Flags: unique registered NBMA address: 10.1.1.3
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 IPv4 Crypto ISAKMP SA C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap. 1002 10.1.1.1 10.1.1.3 ACTIVE 3des sha256 psk 2 23:58:43 Engine-id:Conn-id = SW:2 1001 10.1.1.1 10.1.1.2 ACTIVE 3des sha256 psk 2 23:58:42 Engine-id:Conn-id = SW:1 IPv6 Crypto ISAKMP SA
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 10.1.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.1.1.2/255.255.255.255/47/0)
current_peer 10.1.1.2 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.: 10.1.1.1, remote crypto endpt.: 10.1.1.2
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 http://www.cisco.com/c/en/us/support/docs/security/dynamic-multipoint-vpn-dmvpn/111976-dmvpn-troubleshoot-00.html.
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