Troubleshoot DMVPN Issues

Introduction

This document describes the most common solutions to Dynamic Multipoint VPN (DMVPN) problems.

---

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

---

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

---

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

---

Background Information

This document describes common troubleshooting procedures for DMVPN issues on Cisco IOS and Cisco IOS XE routers. It is intended to help network engineers validate the main DMVPN control-plane and data-plane components before performing deeper troubleshooting or contacting Cisco Technical Support.

The document uses a structured troubleshooting workflow that starts with basic underlay reachability and then progresses through Internet Key Exchange (IKE) / Internet Security Association and Key Management Protocol (ISAKMP) negotiation, IP Security (IPsec) policy validation, Generic Routing Encapsulation (GRE) tunnel operation, Next Hop Resolution Protocol (NHRP) registration, routing protocol adjacencies, one-way encrypted traffic, and Maximum Transmission Unit (MTU), Maximum Segment Size (MSS), or fragmentation issues.

---

Many DMVPN problems are caused by common issues such as unreachable Nonbroadcast Multiaccess (NBMA) addresses, mismatched IKE or IPsec parameters, incorrect pre-shared keys, blocked IKE / Network Address Translation Traversal (NAT-T) / Encapsulating Security Payload (ESP) traffic, incorrect NHRP mappings, routing protocol misconfiguration, or packet size issues caused by GRE and IPsec overhead.

Use this document as a checklist to isolate the failing DMVPN component and verify expected behavior with operational commands and counters. In production networks, use disruptive tests, such as removing IPsec tunnel protection or applying temporary access control lists (ACLs), only during an approved maintenance window or in a controlled environment.

  

Refer to Understand and Use Debug Commands to Troubleshoot IPsec to provide an explanation of common debug commands that are used to troubleshoot IPsec issues.

---

DMVPN Troubleshooting Workflow

Initial Data Collection

1. Sync-up timestamps between the hub and spoke.

---

2. Enable msec debug and log timestamps on the DMVPN devices:

Router(config)#service timestamps debug datetime msec
Router(config)#service timestamps log datetime msec

---

3. Enable terminal exec prompt timestamp for the debugging sessions:

Router#terminal exec prompt timestamp

Verify Basic Underlay Connectivity

Before troubleshooting DMVPN, verify basic underlay connectivity between the hub and spoke NBMA addresses. Ping from the hub NBMA address to the spoke NBMA address, then ping from the spoke NBMA address to the hub NBMA address. These tests must use the physical interface as the source, not the DMVPN tunnel interface.

---

Underlay reachability must work outside the DMVPN tunnel. If the hub and spoke cannot reach each other through their NBMA addresses, DMVPN control-plane and data-plane traffic cannot establish correctly. Use an extended ping to specify the correct source address or source interface.

HUB#ping <spoke-nbma-address> source <hub-nbma-address>
SPOKE#ping <hub-nbma-address> source <spoke-nbma-address>

---

If the ping fails, verify:

• Default/static routes or dynamic routing between the hub and spoke NBMA addresses
• Firewall or ACL rules between the hub and spoke

---

Also, run traceroute from the NBMA source address to verify the underlay path.

Router#traceroute <spoke-nbma-address> source <hub-nbma-address>

---

Use packet capture or run debug commands to confirm basic packet flow:

• Configure an Embedded Packet Capture (EPC)
• Run debug ip icmp or debug ip packet

---

Verify IKEv1/ISAKMP Policy Compatibility

If the configured ISAKMP policies do not match the proposed policy by the remote peer, the router can try the default policy of 65535. If that does not match either, it fails the ISAKMP negotiation. 

---

The router can also return the atts not acceptable message, which can identify Phase1 policy mismatch. These mismatches can include:

• Lifetime
• Hash (SHA, MD5)
• Diffie-Hellman group
• Encryption (AES, 3DES)
• Authentication (Pre-shared key or certificates)

---

The show crypto isakmp sa command shows the ISAKMP SA to be in MM_NO_STATE, which mean the main-mode failed. In the next example, there is a mismatch with the hash algorithm configured on the SPOKE device, which can be seen under the debug crytpo isakmp output:

SPOKE1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.1 172.17.1.1 MM_NO_STATE 0 ACTIVE
172.17.0.1      172.17.1.1      MM_NO_STATE          0 ACTIVE (deleted)

HUB#debug crypto isakmp 
Crypto ISAKMP debugging is on
*Jul 15 00:45:13.007: ISAKMP-PAK: (0):received packet from 172.17.1.1 dport 500 sport 500 Global (R) MM_NO_STATE
*Jul 15 00:45:23.029: ISAKMP: (0):purging SA., sa=80007BE36567F040, delme=80007BE36567F040
*Jul 15 00:45:24.878: ISAKMP-PAK: (0):received packet from 172.17.1.1 dport 500 sport 500 Global (N) NEW SA
*Jul 15 00:45:24.879: ISAKMP: (0):Created a peer struct for 172.17.1.1, peer port 500
*Jul 15 00:45:24.879: ISAKMP: (0):New peer created peer = 0x80007BE3D73BBED0 peer_handle = 0x8000000040000008
*Jul 15 00:45:24.879: ISAKMP: (0):Locking peer struct 0x80007BE3D73BBED0, refcount 1 for crypto_isakmp_process_block
*Jul 15 00:45:24.879: ISAKMP: (0):local port 500, remote port 500
*Jul 15 00:45:24.879: ISAKMP: (0):insert sa successfully sa = 80007BE36567F040
*Jul 15 00:45:24.879: ISAKMP: (0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jul 15 00:45:24.879: ISAKMP: (0):Old State = IKE_READY  New State = IKE_R_MM1 

*Jul 15 00:45:24.880: ISAKMP: (0):processing SA payload. message ID = 0
*Jul 15 00:45:24.880: ISAKMP: (0):processing vendor id payload
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID seems Unity/DPD but major 69 mismatch
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID is NAT-T RFC 3947
*Jul 15 00:45:24.880: ISAKMP: (0):processing vendor id payload
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID seems Unity/DPD but major 245 mismatch
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID is NAT-T v7
*Jul 15 00:45:24.880: ISAKMP: (0):processing vendor id payload
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID seems Unity/DPD but major 157 mismatch
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID is NAT-T v3
*Jul 15 00:45:24.880: ISAKMP: (0):processing vendor id payload
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID seems Unity/DPD but major 123 mismatch
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID is NAT-T v2
*Jul 15 00:45:24.880: ISAKMP: (0):found peer pre-shared key matching 172.17.1.1
*Jul 15 00:45:24.880: ISAKMP: (0):local preshared key found
*Jul 15 00:45:24.880: ISAKMP: (0):Scanning profiles for xauth ...
*Jul 15 00:45:24.880: ISAKMP: (0):Checking ISAKMP transform 1 against priority 10 policy
*Jul 15 00:45:24.880: ISAKMP: (0):      encryption AES-CBC
*Jul 15 00:45:24.880: ISAKMP: (0):      keylength of 128
*Jul 15 00:45:24.880: ISAKMP: (0):      hash SHA512
*Jul 15 00:45:24.881: ISAKMP: (0):      default group 19
*Jul 15 00:45:24.881: ISAKMP: (0):      auth pre-share
*Jul 15 00:45:24.881: ISAKMP: (0):      life type in seconds
*Jul 15 00:45:24.881: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80 
*Jul 15 00:45:24.881: ISAKMP-ERROR: (0):Hash algorithm offered does not match policy!
*Jul 15 00:45:24.881: ISAKMP-ERROR: (0):atts are not acceptable. Next payload is 0
*Jul 15 00:45:24.881: ISAKMP-ERROR: (0):no offers accepted!
*Jul 15 00:45:24.884: ISAKMP-ERROR: (0):phase 1 SA policy not acceptable! (local 172.17.0.1 remote 172.17.1.1)
*Jul 15 00:45:24.884: ISAKMP: (0):: incrementing error counter on sa, attempt 1 of 5: construct_fail_ag_init
*Jul 15 00:45:24.884: ISAKMP-PAK: (0):sending packet to 172.17.1.1 my_port 500 peer_port 500 (R) MM_NO_STATE
*Jul 15 00:45:24.885: ISAKMP: (0):Sending an IKE IPv4 Packet.
*Jul 15 00:45:24.886: ISAKMP: (0):peer does not do paranoid keepalives.
*Jul 15 00:45:24.886: ISAKMP-ERROR: (0):deleting SA reason "Phase1 SA policy proposal not accepted" state (R) MM_NO_STATE (peer 172.17.1.1)

---

Verify Pre-Shared Key Configuration

During IKE Phase 1, both peers independently use the configured pre-shared key, the Diffie-Hellman shared secret, and other values exchanged during the negotiation to compute a cryptographic hash; each router then verifies the hash received from its peer matches its own calculation, proving both sides possess the same pre-shared key without transmitting the key itself.

---

If pre-shared keys are not the same on both sides, the negotiation fails. The router then returns a sanity check failed message. Enable the debugs (debug crypto isakmp and debug crypto ipsec) to observe these messages:

HUB#debug crypto ipsec
Crypto IPSEC debugging is on

HUB#debug crypto isakmp 
Crypto ISAKMP debugging is on
*Jul 15 01:11:32.971: ISAKMP: (0):processing KE payload. message ID = 0
*Jul 15 01:11:32.986: ISAKMP: (0):processing NONCE payload. message ID = 0
*Jul 15 01:11:32.986: ISAKMP: (0):found peer pre-shared key matching 172.17.1.1
*Jul 15 01:11:32.987: ISAKMP: (1007):processing vendor id payload
*Jul 15 01:11:32.987: ISAKMP: (1007):vendor ID is DPD
*Jul 15 01:11:32.987: ISAKMP: (1007):processing vendor id payload
*Jul 15 01:11:32.987: ISAKMP: (1007):speaking to another IOS box!
*Jul 15 01:11:32.987: ISAKMP: (1007):processing vendor id payload
*Jul 15 01:11:32.987: ISAKMP: (1007):vendor ID seems Unity/DPD but major 40 mismatch
*Jul 15 01:11:32.987: ISAKMP: (1007):vendor ID is XAUTH
*Jul 15 01:11:32.987: ISAKMP: (1007):received payload type 20
*Jul 15 01:11:32.987: ISAKMP: (1007):His hash no match - this node outside NAT
*Jul 15 01:11:32.987: ISAKMP: (1007):received payload type 20
*Jul 15 01:11:32.987: ISAKMP: (1007):No NAT Found for self or peer
*Jul 15 01:11:32.987: ISAKMP: (1007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Jul 15 01:11:32.987: ISAKMP: (1007):Old State = IKE_R_MM3  New State = IKE_R_MM3 

*Jul 15 01:11:32.987: ISAKMP-PAK: (1007):sending packet to 172.17.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH
*Jul 15 01:11:32.987: ISAKMP: (1007):Sending an IKE IPv4 Packet.
*Jul 15 01:11:32.988: ISAKMP: (1007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Jul 15 01:11:32.988: ISAKMP: (1007):Old State = IKE_R_MM3  New State = IKE_R_MM4 

*Jul 15 01:11:33.010: ISAKMP-PAK: (1007):received packet from 172.17.1.1 dport 500 sport 500 Global (R) MM_KEY_EXCH
*Jul 15 01:11:33.010: ISAKMP-PAK-ERROR: (1007):reserved not zero on ID payload!
*Jul 15 01:11:33.010: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 172.17.1.1 failed its sanity check or is malformed

---

Verify IPsec Transform Set Compatibility

If the IPsec transform-set is not compatible or mismatched on the two IPsec devices, the IPsec negotiation fails. Run the debug crypto isakmp and debug crypto ipsec commands to help identify the issue:

HUB#debug crypto isakmp 
Crypto ISAKMP debugging is on
*Jul 14 23:41:24.341: ISAKMP: (1003):purging node 3041685630
*Jul 14 23:41:39.807: ISAKMP-PAK: (1003):received packet from 172.17.1.1 dport 500 sport 500 Global (R) QM_IDLE      
*Jul 14 23:41:39.807: ISAKMP: (1003):set new node 1354194457 to QM_IDLE      
*Jul 14 23:41:39.807: ISAKMP: (1003):processing HASH payload. message ID = 1354194457
*Jul 14 23:41:39.807: ISAKMP: (1003):processing SA payload. message ID = 1354194457
*Jul 14 23:41:39.807: ISAKMP: (1003):Checking IPSec proposal 1
*Jul 14 23:41:39.807: ISAKMP: (1003):transform 1, ESP_AES 
*Jul 14 23:41:39.807: ISAKMP: (1003):   attributes in transform:
*Jul 14 23:41:39.807: ISAKMP: (1003):      encaps is 1 (Tunnel)
*Jul 14 23:41:39.807: ISAKMP: (1003):      SA life type in seconds
*Jul 14 23:41:39.807: ISAKMP: (1003):      SA life duration (basic) of 3600
*Jul 14 23:41:39.807: ISAKMP: (1003):      SA life type in kilobytes
*Jul 14 23:41:39.807: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0 
*Jul 14 23:41:39.813: ISAKMP: (1003):      authenticator is HMAC-SHA512
*Jul 14 23:41:39.813: ISAKMP: (1003):      key length is 128
*Jul 14 23:41:39.813: ISAKMP: (1003):atts are acceptable.
*Jul 14 23:41:39.813: ISAKMP-ERROR: (1003):IPSec policy invalidated proposal with error 256
*Jul 14 23:41:39.815: ISAKMP-ERROR: (1003):phase 2 SA policy not acceptable! (local 172.17.0.1 remote 172.17.1.1)
*Jul 14 23:41:39.815: ISAKMP: (1003):set new node 460336619 to QM_IDLE      
*Jul 14 23:41:39.815: ISAKMP: (1003):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
        spi 9223508253390078112, message ID = 460336619
*Jul 14 23:41:39.815: ISAKMP-PAK: (1003):sending packet to 172.17.1.1 my_port 500 peer_port 500 (R) QM_IDLE      
*Jul 14 23:41:39.815: ISAKMP: (1003):Sending an IKE IPv4 Packet.
*Jul 14 23:41:39.816: ISAKMP: (1003):purging node 460336619
*Jul 14 23:41:39.816: ISAKMP-ERROR: (1003):deleting node 1354194457 error TRUE reason "QM rejected"

HUB#debug crypto ipsec 
Crypto IPSEC debugging is on
*Jul 14 23:43:48.909: IPSEC(validate_proposal_request): proposal part #1
*Jul 14 23:43:48.910: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 172.17.0.1:0, remote= 172.17.1.1:0,
    local_proxy= 172.17.0.1/255.255.255.255/47/0,
    remote_proxy= 172.17.1.1/255.255.255.255/47/0,
    protocol= ESP, transform= esp-aes esp-sha512-hmac (Tunnel), esn= FALSE,
    lifedur= 0s and 0kb, 
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
*Jul 14 23:43:48.916: map_db_find_best did not find matching mapcrypto_mapdb_find_map Fail to find matching policy ivrf 0, fvrf 0, flags 1, ike_profile NULL, local_proxy 172.17.0.1, remote_proxy 172.17.1.1, km_local 172.17.0.1, km_remote 172.17.1.1, km_local_port 65535, km_remote_port 65535 
*Jul 14 23:43:48.916: IPSEC(ipsec_process_proposal): transform not supported: {esp-aes esp-sha512-hmac }
HUB#undebug all
All possible debugging has been turned off
HUB#

---

Run the show crypto ipsec transform-set command on both sides of the tunnel to help identify a mismatch. In this example, SPOKE is proposing AES encryption, SHA-512 integrity and Tunnel Mode, which differs from HUB parameters:

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

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

---

Verify ISAKMP Traffic Filtering

The next example shows the VPN tunnel flapping:

HUB#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.1      172.17.2.1      QM_IDLE           1042 ACTIVE
172.17.0.1      172.17.2.1      MM_NO_STATE       1040 ACTIVE (deleted)
172.17.0.1      172.17.1.1      QM_IDLE           1041 ACTIVE
172.17.0.1      172.17.1.1      MM_NO_STATE       1039 ACTIVE (deleted)

---

Run the debug crypto isakmp command to verify the spoke router sends UDP 500 packet:

SPOKE1#debug crypto isakmp
04:14:44.450: ISAKMP:(0):Old State = IKE_READY  
                       New State = IKE_I_MM1
04:14:44.450: ISAKMP:(0): beginning Main Mode exchange
04:14:44.450: ISAKMP:(0): sending packet to 172.17.0.1 
              my_port 500 peer_port 500 (I) MM_NO_STATE
04:14:44.450: ISAKMP:(0):Sending an IKE IPv4 Packet.
04:14:54.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:14:54.450: ISAKMP (0:0): incrementing error counter on sa, 
              attempt 1 of 5: retransmit phase 1
04:14:54.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
04:14:54.450: ISAKMP:(0): sending packet to 172.17.0.1 
              my_port 500 peer_port 500 (I) MM_NO_STATE
04:14:54.450: ISAKMP:(0):Sending an IKE IPv4 Packet.
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:15:04.450: ISAKMP (0:0): incrementing error counter on sa, 
              attempt 2 of 5: retransmit phase 1
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE

---

The previous debug output shows the spoke router sends the UDP 500 packet in every 10 seconds.

Check with the ISP to verify if the spoke router is directly connected and make ensure they allow UDP 500 traffic.

After the ISP allows UDP 500, you can use an EPC or add an inbound ACL on the hub router in the ISP facing interface. To ensure UDP 500 traffic comes into the router, run the show ip access-list command to verify whether hit counts increase:

HUB#show ip access-lists 
Extended IP access list 101
    10 permit udp host 172.17.1.1 host 172.17.0.1 eq isakmp log (23 matches)
    20 permit udp host 172.17.2.1 host 172.17.0.1 eq isakmp log (21 matches)
    30 permit ip any any (350 matches)

Verify GRE Tunnel Operation

When DMVPN is not functioning properly, a troubleshooting scenario can used to verify the GRE tunnels operate correctly without IPsec encryption prior to troubleshooting any IPsec related issues.

---

Before removing tunnel protection, save the current tunnel configuration (from both sides of the tunnel) by running the show running-config interface Tunnel<interface-number> command and confirm the IPsec profile name in use:

HUB#show running-config interface tunnel0
Building configuration...

Current configuration : 332 bytes
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip split-horizon eigrp 100
 ip nhrp authentication CISCO
 ip nhrp network-id 100
 ip nhrp redirect
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN
end

---

Recommended validations:

• Confirm the tunnel interface is in an up/up state by running the show interface Tunnel<interface-number> command.
• Ping the remote tunnel IP address
• Confirm the spokes successfully registered with the hub running the show ip nhrp command.
• Validate the hub sees all spokes, and peer state is UP running the show dmvpn command.

---

Temporarily removing tunnel protection can help isolate whether the problem is related to GRE/NHRP/routing or to IPsec encryption. If GRE works without IPsec protection, the underlay path and tunnel logic are likely functional, and the issue is likely related to IKE/IPsec negotiation, transform sets, profiles, keys, or encrypted traffic filtering. For this test to be valid, tunnel protection must be removed on both ends of the DMVPN path being tested, including the hub and the spoke tunnel interface.

---

Verify NHRP Registration

The VPN tunnel between hub and spoke is up, but cannot pass data traffic:

SPOKE1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.1      172.17.1.1      QM_IDLE           1039 ACTIVE

SPOKE1#show crypto ipsec sa         

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.17.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
   current_peer 172.17.0.1 port 500
     PERMIT, flags={origin_is_acl,}
 #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #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.: 172.17.1.1, remote crypto endpt.: 172.17.0.1
     plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0x9436DE5(155413989)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xA408C808(2752038920)

---

The output shows encrypted traffic is sent, but return traffic is not received from the other end of the tunnel. Verify the NHS entry on the spoke router.

In this example, the NHS registration request failed. To resolve the issue, verify the spoke tunnel interface uses the correct hub tunnel IP address as the NHS and the correct NBMA address in the NHRP map:

SPOKE1#show ip nhrp nhs detail 
Legend: E=Expecting replies, R=Responding, W=Waiting, D=Dynamic
Tunnel0:
172.17.0.1   E priority = 0 cluster = 0  req-sent 0  req-failed 23  repl-recv 0 


Pending Registration Requests:
Registration Request: Reqid 110, Ret 64  NHS 172.17.0.1 expired (Tu0)

---

The reason for the failure was the spoke configuration in the NHS server IP address pointed to the hub NBMA or physical address instead of the hub tunnel IP address. The ip nhrp nhs command on a spoke must reference the hub DMVPN tunnel interface IP address. Configuring the NHS with the hub NBMA address instead of the tunnel address prevents successful NHRP registration.

---

In DMVPN, running the ip nhrp nhs command identifies the NHRP Next Hop Server by its tunnel IP address. The ip nhrp map command is then used to map that hub tunnel IP address to the hub NBMA address, which is the reachable underlay or physical address:

SPOKE1#show running-config interface tunnel0
Building configuration...

Current configuration : 374 bytes
!
interface Tunnel0
 ip address 10.0.0.5 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication CISCO
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp network-id 100
 ip nhrp nhs 172.17.0.1
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN
end

---

The next output displays the configuration example with the corrected entry for the NHS server:

SPOKE1#show running-config interface tunnel0
Building configuration...

Current configuration : 372 bytes
!
interface Tunnel0
 ip address 10.0.0.5 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication CISCO
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp network-id 100
 ip nhrp nhs 10.0.0.1
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN
end

---

Now, verify the NHS entry and IPsec encrypt/decrypt counters:

SPOKE1#show ip nhrp nhs detail 
Legend: E=Expecting replies, R=Responding, W=Waiting, D=Dynamic
Tunnel0:
10.0.0.1  RE  priority = 0 cluster = 0  req-sent 4 req-failed 0 repl-recv 4 (00:01:08 ago)

SPOKE1#show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.17.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
   current_peer 172.17.0.1 port 500
     PERMIT, flags={origin_is_acl,}
 #pkts encaps: 231, #pkts encrypt: 231, #pkts digest: 231 #pkts decaps: 136, #pkts decrypt: 136, #pkts verify: 136
    #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.: 172.17.1.1, remote crypto endpt.: 172.17.0.1
     plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0xA2D1748A(2731635850)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x88246F16(2284089110)

---

Verify Security Association Lifetimes

Run these commands to verify the current IKE/IPsec Security Association (SA) lifetimes and the time remaining before the next renegotiation:

• show crypto isakmp policy

• show crypto isakmp sa detail
• show crypto ipsec security-association lifetime

• show crypto ipsec sa

• show crypto ipsec sa peer <peer-nbma-address>

---

Common SA lifetimes defaults are 24 hours (86400 seconds) for IKEv1/ISAKMP SAs and 1 hour (3600 seconds) for IPsec SAs. However, always verify the configured and negotiated lifetime values on both peers.

---

Review the remaining lifetime values in the command output. If the remaining lifetime is close to the configured lifetime, the SA was recently negotiated. This can be normal after the tunnel first comes up or after a scheduled rekey. To determine whether the behavior is normal or whether the tunnel is bouncing, monitor the SA state and lifetime values over time.

---

Expected behavior usually shows:

• The remaining lifetime decreases over time.
• The SAs rekey near the expected lifetime expiration.
• Packet counters continue to increase before and after rekey.
• No repeated tunnel down/up messages appear in the logs.

---

Possible bouncing or repeated failure can show:

• The SA lifetime repeatedly resets to the full configured value before the expected rekey time.
• The IKE or IPsec SA disappears and is recreated frequently.
• show crypto isakmp sa repeatedly changes state or returns to negotiation states.
• IPsec encapsulation and decapsulation counters stop increasing during the event.
• Syslog messages show repeated IKE/IPsec negotiation failures, deletes, or reauthentication events.

SPOKE1#show crypto isakmp policy

Global IKE policy
Protection suite of priority 10
        encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #14 (2048 bit)
        lifetime: 86400 seconds, no volume limit

SPOKE1#show 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.

1044  172.17.1.1      172.17.0.1                                       ACTIVE aes  sha    psk  14 23:57:09     
       Engine-id:Conn-id =  SW:44

IPv6 Crypto ISAKMP SA

SPOKE1#show crypto ipsec security-association lifetime
Security association lifetime: 4608000 kilobytes/3600 seconds
Multi SNS : Disabled 

SPOKE1#show crypto ipsec sa | i sa timing|ident|inbound esp|outbound esp 
   local  ident (addr/mask/prot/port): (172.17.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
     inbound esp sas:
         sa timing: remaining key lifetime (k/sec): (4607994/3422)
     outbound esp sas:
         sa timing: remaining key lifetime (k/sec): (4607996/3422)

---

Verify One-Way IPsec Traffic

If the VPN tunnel between a spoke-to-spoke router is up, but cannot pass data traffic. Use the IPsec counters to identify the failing direction:

• If encaps/encrypt increases but decaps/decrypt do not increase, the router is sending encrypted traffic but not receiving valid return IPsec traffic.
• If decaps/decrypt increases, the router is receiving and decrypting IPsec traffic.
• Compare both spokes to determine which direction is failing.

---

SPOKE1#show crypto ipsec sa peer 172.17.2.1

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.17.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.2.1/255.255.255.255/47/0)
   current_peer 172.17.2.1 port 500
     PERMIT, flags={origin_is_acl,}
 #pkts encaps: 6, #pkts encrypt: 6, #pkts digest: 6 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #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.: 172.17.1.1, remote crypto endpt.: 172.17.2.1
     plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0x140FA971(336570737)
     PFS (Y/N): N, DH group: none

SPOKE2#show crypto ipsec sa peer 172.17.1.1

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.2.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.17.2.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.1.1/255.255.255.255/47/0)
   current_peer 172.17.1.1 port 500
     PERMIT, flags={origin_is_acl,}
 #pkts encaps: 11, #pkts encrypt: 11, #pkts digest: 11 #pkts decaps: 6, #pkts decrypt: 6, #pkts verify: 6
    #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.: 172.17.2.1, remote crypto endpt.: 172.17.1.1
     plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0x931B398E(2468034958)
     PFS (Y/N): N, DH group: none

---

Verify Routing Protocol Configuration and Adjacencies

DMVPN routing behavior depends on the DMVPN phase and the routing protocol running over the tunnel. The routing design determines whether spoke-to-spoke traffic can establish a direct dynamic tunnel or whether it continues to traverse the Hub.

As a result, the routing recommendations differ between DMVPN Phase 2 and DMVPN Phase 3. A configuration that is appropriate for Phase 2 can prevent the intended routing behavior in Phase 3. While a Phase 3 deployment can support default routing and route summarization at the hub designs are generally not appropriate for Phase 2.

---

DMVPN Phase 2 Routing Behavior

In DMVPN Phase 2, spoke-to-spoke tunnels depend heavily on the routing table. For direct spoke-to-spoke communication to work, each spoke must learn remote spoke networks with the remote spoke tunnel IP address as the next hop.

---

For example:

• Routes advertised from a spoke must preserve that spoke Tunnel IP address as the next hop.
• Other spokes must receive those routes with the originating spoke Tunnel IP address as the next hop.
• The hub must not rewrite the next hop to its own Tunnel IP address for routes learned from spokes.

---

By preserving the remote spoke Tunnel IP address as the next hop, the spoke can resolve that Tunnel IP to its corresponding NBMA address through NHRP and establish a direct spoke-to-spoke tunnel. Spoke-to-spoke connectivity depends on the routing protocol preserving the original spoke as the next hop (for example, in the case of EIGRP by running the no ip next-hop-self eigrp command.)

---

Key Phase 2 Requirements

• NHRP is required for spoke registration to the hub.
• mGRE is used on the hub and spokes.
• NHRP is required for spoke-to-spoke resolution.
• Spoke-to-spoke tunnels are initiated by the originating spoke based on the routing table next hop.
• The hub must preserve the original spoke next hop for remote spoke routes.
• Summarization or default routing from the hub toward the spokes is generally not suitable because it causes the hub to remain in the data path.

---

EIGRP Considerations for Phase 2

On the hub tunnel interface, EIGRP commonly requires:

HUB(config)#interface tunnel<tunn-number>
HUB(config-if)#no ip next-hop-self eigrp <as-number>
HUB(config-if)#no ip split-horizon eigrp <as-number>

---

These commands allow the hub to advertise spoke routes to other spokes without changing the next hop to itself.

Avoid summarizing spoke routes at the hub in a Phase 2 design. If the hub advertises a summary route or default route for spoke networks, the spokes point to the hub as the next hop, which defeats the purpose of Phase 2 spoke-to-spoke forwarding.

---

OSPF Considerations for Phase 2

For OSPF over DMVPN Phase 2, the OSPF network type must support hub-and-spoke adjacency while preserving correct forwarding behavior.

A common design is to use OSPF broadcast network type on the tunnel for both hub and spokes:

Router(config)#interface tunnel<tunn-number>
Router(config-if)#ip ospf network broadcast

---

Configure the spokes with OSPF priority 0 so they do not become the DR:

SPOKE(config)#interface tunnel<tunn-number>
SPOKE(config-if)#ip ospf priority 0

This helps ensure the hub maintains routing adjacency control while the routing design still supports spoke-to-spoke forwarding.

---

DMVPN Phase 3 Routing Behavior

DMVPN Phase 3 simplifies routing compared to Phase 2. In Phase 3, spokes can point to the hub as the next hop for remote networks, including networks behind other spokes. This allows the hub to advertise summary routes or default routes to the spokes.

When a spoke sends traffic to another spoke through the hub, the hub forwards the initial packet and sends an NHRP redirect message back to the sending spoke. The redirect tells the spoke that a better path exists. The spoke then sends an NHRP resolution request to discover the remote spoke NBMA address and builds a direct spoke-to-spoke tunnel. In other words, Phase 3 allows simplified routing while still enabling spoke-to-spoke tunnels through NHRP redirect and shortcut behavior.

---

Key Phase 3 Requirements

• NHRP is required for spoke registration to the hub.
• mGRE is used on the hub and spokes.
• NHRP is used for spoke-to-spoke resolution.
• The hub can remain the routing next hop.
• Supports the use of route summarization and default routing at the Hub.
• Spoke-to-spoke tunnels are initiated after the Hub sends an NHRP Redirect indicating that a better path exists.
• Spokes use NHRP Shortcut to install optimized forwarding entries toward remote spokes.

---

NHRP Shortcut and Redirect Requirements

On the hub tunnel interface, enable NHRP redirect:

HUB(config)#interface tunnel<tunn-number>
HUB(config-if)#ip nhrp redirect

---

On each spoke tunnel interface, enable NHRP shortcut:

SPOKE(config)#interface tunnel<tunn-number>
SPOKE(config-if)#ip nhrp shortcut

---

The hub uses NHRP Redirect to notify the spoke of a better path, and the spoke uses NHRP Shortcut to install the optimized spoke-to-spoke forwarding path.

---

EIGRP Considerations for Phase 3

For EIGRP in a Phase 3 design, the hub can advertise summary routes or default routes to the spokes. Unlike Phase 2, the hub does not need to preserve the original spoke next hop.

---

On the hub tunnel interface:

• Keep no ip split-horizon eigrp <as-number> so the hub can advertise routes learned from one spoke to the other spokes.
• Remove no ip next-hop-self eigrp <as-number> to allow the hub to remain the routing next hop, which is the expected behavior in DMVPN Phase 3.
• Configure route summarization as needed to simplify routing and reduce the size of the routing table.

---

OSPF Considerations for Phase 3

For OSPF in DMVPN Phase 3, the point-to-multipoint network type is commonly configured on both the Hub and the spokes running the ip ospf network point-to-multipoint command. This network type models the hub as having multiple point-to-point neighbor relationships, avoids DR/BDR elections, and aligns well with the Phase 3 architecture. This is where OSPF advertises routes through the hub while NHRP Redirects and Shortcuts dynamically optimize spoke-to-spoke forwarding. This network type also allows the removal of OSPF priority with the no ip ospf priority command.

---

If spokes cannot establish a routing protocol neighbor relationship with the hub, verify the NHRP multicast mapping is configured correctly on the hub tunnel interface.

Dynamic routing protocols such as EIGRP and OSPF use multicast packets to discover and maintain neighbors. In a DMVPN network that uses multipoint GRE and IPsec, the hub must dynamically map multicast traffic to registered spokes. Without the correct multicast mapping, the hub cannot forward routing protocol multicast packets correctly, which can prevent routing adjacencies from forming or cause them to flap.

HUB#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.0.0.9                Tu0                      13 00:00:24    1  5000  1  0
0   10.0.0.5                Tu0                      12 00:00:24    1  5000  1  0
HUB#
*Jul 17 01:17:42.102: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.5 (Tunnel0) is down: retry limit exceeded *Jul 17 01:17:42.380: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.9 (Tunnel0) is down: retry limit exceeded
HUB#

HUB#show ip route eigrp 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 172.17.0.2 to network 0.0.0.0

HUB#

---

As a first step, verify if NHRP multicast mapping ip nhrp map multicast dynamic is configured in the hub tunnel interface.

---

If the this command is missing, configure it as in the next example:

HUB(config)#interface tunnel0
HUB(config-if)#ip nhrp map multicast dynamic

---

Once the hub learns the spoke NHRP registrations and dynamically creates multicast mappings, the routing protocol neighbors can establish successfully and routes to the spokes are learned:

HUB#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.0.0.5                Tu0                      12 00:00:17   19  1362  0  46
0   10.0.0.9                Tu0                      12 00:00:17    9  1362  0  39

HUB#show ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 172.17.0.2 to network 0.0.0.0

D 192.168.2.0/24 [90/27008000] via 10.0.0.5, 00:08:04, Tunnel0 D 192.168.11.0/24 [90/27008000] via 10.0.0.9, 00:08:05, Tunnel0

---

When routing protocol neighbors do not form, verify the following:

• The command ip nhrp map multicast dynamic is configured under the hub tunnel interface.
• The routing protocol is enabled on the tunnel interface.
• The routing protocol hello packets are not blocked by ACLs or firewall policy.
• The tunnel interfaces are up/up.
• IPsec SAs are established and packet counters are incrementing.
• The spoke configuration includes the correct multicast mapping toward the hub, such as ip nhrp map multicast <hub-nbma-address> command.

---

Verify MTU, MSS, and Fragmentation Issues

In scenarios where users can reach the DMVPN network, but access to a server through the DMVPN tunnel fails or behaves inconsistently. For example, login to a server fails, application sessions hang, or file transfers do not complete.

---

This type of issue can be related to MTU, MSS, or fragmentation because DMVPN traffic adds GRE and IPsec overhead to the original packet. If the resulting packet is larger than the supported path MTU, packets can be fragmented or dropped in the underlay network.

---

Some of the common symptoms of MTU or MSS issues are:

• Ping works, but TCP applications fail.
• Small packets pass, but large packets fail.
• Server login starts but hangs or times out.
• File transfers fail or stall.
• Web, Secure Shell (SSH), Remote Desktop Protocol (RDP), or database sessions connect but do not pass data reliably.
• The issue affects some applications but not others.
• The issue is more visible when the DF bit is set and fragmentation is not allowed.

---

First, confirm the DMVPN control plane is stable, then, verify if large packets fail across the tunnel. Use extended ping with the DF bit set and vary the packet size ping <remote-server-ip> size <packet-size> df-bit source <interface|address>. Test from one DMVPN endpoint or LAN subnet toward the remote server or remote tunnel endpoint. Start with a smaller packet size and gradually increase it. If smaller packets succeed but larger packets fail, the path can have an MTU or fragmentation issue.

---

To reduce fragmentation for TCP traffic, configure the tunnel interface with a lower MTU and adjust the TCP MSS.

Router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface tunnel0
Router(config-if)#ip mtu 1400
Router(config-if)#ip tcp adjust-mss 1360

The ip mtu 1400 command lowers the tunnel interface MTU to account for GRE and IPsec overhead and the ip tcp adjust-mss 1360 command adjusts the TCP MSS value for TCP sessions that traverse the tunnel, which helps prevent endpoints from sending TCP segments that are too large for the path.

If needed, IPsec fragmentation can also be configured globally with the crypto ipsec fragmentation after-encryption command. You can also configure the tunnel path-mtu-discovery command to dynamically discover the MTU size.

---

---

Related Information

• Dynamic Multipoint VPN (DMVPN)
• IPSec Negotiation/IKE Protocols

• Cisco VPN Technologies Reference Guide

   
• Cisco Technical Support & Downloads

Revision History

Revision	Publish Date	Comments
4.0	20-Jul-2026	Updated spelling, grammar, spacing, inserted horizontal lines to separate sections for readability.
3.0	29-Aug-2024	Corrected links, corrected CCW alerts, Recertification, title case.
2.0	24-Mar-2023	Corrected links, corrected CCW alerts. Recertification.
1.0	27-Apr-2010	Initial Release