This document contains the most common solutions to Dynamic Multipoint VPN (DMVPN) problems. Many of these solutions can be implemented prior to the in-depth troubleshooting of the DMVPN connection. This document is presented as a checklist of common procedures to try before you begin to troubleshoot a connection and call Cisco Technical Support.

The information in this document is based on these software and hardware versions:

Cisco IOS

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, make sure that you understand the potential impact of any command.

These pings should go directly out the physical interface, not through the DMVPN tunnel. Hopefully, there is not a firewall that blocks ping packets. If this does not work, check the routing and any firewalls between the hub and spoke routers.

Also, use traceroute to check the path that the encrypted tunnel packets are taking.

Use the debug and show commands to verify no connectivity:

debug ip icmp

debug ip packet

Note: The debug ip packet command generates a substantial amount of output and uses a substantial amount of system resources. This command should be used with caution in production networks. Always use with the access-list command.

Check with ISP to see if the spoke router is directly connected to the ISP router to make sure they are allowing udp 500 traffic.

After ISP allowed udp 500, add inbound ACL in egress interface, which is tunnel source to allow udp 500 to make sure udp 500 traffic is coming into the router. Use the show access-list command to verify whether hit counts are incrementing:

Use these commands to verify the current SA lifetime and the time for next renegotiation:

show crypto isakmp sa detail

show crypto ipsec sa peer <NBMA-address-peer>

Notice SA lifetime values. If they are close to the configured lifetimes (default is 24 hrs for ISAKMP and 1 hour for IPsec), then that means these SAs have been recently negotiated. If you look a little while later and they have been re-negotiated again, then the ISAKMP and/or IPsec may be bouncing up and down.

There is no decap packets in spoke1, which means esp packets are dropped somewhere in the path return from spoke2 towards spoke1.

The spoke2 router shows both encap and decap, which means that ESP traffic is filtered before reaching spoke2. It may happen at the ISP end at spoke2 or at any firewall in path between spoke2 router and spoke1 router. After allowing ESP (IP Protocol 50), spoke1 and spoke2 both show encaps and decaps counters are incrementing.