Ask the Expert : Dynamic Multipoint VPN (DMVPN) Troubleshooting

[Vidhi Mujumdar]

Dynamic Multipoint VPN (DMVPN) is a Cisco IOS/IOS-XE Software solution for building scalable IPsec Virtual Private Networks (VPNs). Cisco DMVPN uses a centralized architecture to provide easier implementation and management for deployments that require granular access controls for diverse user communities, including mobile workers, telecommuters, and extranet users. Cisco DMVPN allows branch locations to communicate directly with each other over the public or private WAN or Internet but doesn't require a permanent VPN connection between sites. It enables zero-touch deployment of IPsec VPNs and improves network performance by reducing latency and jitter, while optimizing head office bandwidth utilization.  This session will provide some insight into the base components involved in DMVPN and the different phases of deployment (hub-spoke model v. dynamic full mesh). It will focus on the layered troubleshooting approach required when working on DMVPN-related network issues and how it can be used to troubleshoot commonly seen problems in the field.

Ask questions from Tuesday June 7 to June 17, 2016

Featured Experts

Frank DeNofa has been a Customer Support Engineer in the Technical Assistance Center VPN team in RTP since 2013. He has expertise in VPN technologies with a focus on site-to-site VPN solutions such as DMVPN, GETVPN, and FlexVPN. Frank holds a Bachelor's Degree in Applied Networking and Systems Administration with a focus on routing and security from Rochester Institute of Technology in Rochester, NY. His non-networking interests include hockey, CrossFit, and cooking.

Hamzah Kardame has been a Customer Support Engineer in the Technical Assistance Center Security team at Cisco since 2010. His area of expertise lies in the VPN space on both IOS/IOS-XE based platforms as well as on ASAs, focusing on VPN solutions such as DMVPN, GETVPN and FlexVPN, in addition to Public Key Infrastructure (PKI). He holds a CCIE certification in Security (#35596). Hamzah graduated with a Bachelor’s Degree in Electronics and Communication from PESIT at Bangalore, India. His other areas of interest include reading, soccer and traveling.

Find other  https://supportforums.cisco.com/expert-corner/events.

** Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions

https://supportforums.cisco.com/expert-corner/events ">https://supportforums.cisco.com/expert-corner/events.

We look forward to your participation. This event is open to all, including partners. Please Share this event in your social channels. Have a technical question? Get answers here before opening a TAC case by visiting the Cisco Support Community.

 

[dacoty100]

how can we download the slides from the presentation today?

[Vidhi Mujumdar]

you can download the slides from here : https://supportforums.cisco.com/event/13021656/webcast-dynamic-multipoint-vpn-dmvpn-troubleshooting

[rohanrounak]

Thanks for sharing the details Vidhi. The session was really very helpful.

[acetate · Accepted solution]

How can you replay this webcast?

[Vidhi Mujumdar]

We will post the recording of the webcast by tomorrow.

[Monica Lluis · Accepted solution]

The recording of this webcast is posted at https://supportforums.cisco.com/video/13040426/webcast-video-dynamic-multipoint-vpn-troubleshooting

Enjoy.

Monica

[Amal Ahmadov]

Dears,

In section 2 of DMVPN Phase 3 - Deep Dive slide page it was mentioned that  hub receives and forwards data packet on tunnel interfaces with the same NHRP Network-id. 

As far as I know there are no requirements that the NHRP network-ids must match on hub and spokes.

Please, correct if I am mistaken.

Best regards,

Amal

[Frank DeNofa]

Amal,

When saying "hub receives and forwards data packet on tunnel interfaces with the same NHRP Network-id" we are talking about the tunnel interfaces on the Hub router. For example, if the Hub received the data packet on Tunnel1 (NHRP network-id 1) and forwarded out Tunnel2 (NHRP network-id 2) a redirect would not be sent. However, if we forwarded the packet out Tunnel3 (NHRP network-id 1) or back out Tunnel1, a direct would be sent.

That said, you are definitely correct; NHRP network-ids are locally significant and do not need to match between Hubs and Spokes.

HTH,

Frank

[Amal Ahmadov]

Thanks. That makes sense.

[Frank DeNofa]

A question from the webcast Q&A:

What feature in DMVPN makes it not interoperable with other vendors, since IKEv2 is multivendor

While IKEv2 is a standardized protocol based on RFC 5996, the other components of DMVPN (multipoint GRE and NHRP) are often not (correctly) implemented by other vendors. Cisco is the only vendor which officially supports DMVPN as a solution, although I have heard of other vendors hacking together a solution which is some-what compatible.

-Frank

[Frank DeNofa]

A question from the webcast Q&A:

in phase 3 can we remove "no ip next-hop-self eigrp " command ?

With respect to the Hub, yes; in fact it is a requirement for your Hub router to be the next hop for all routers on the tunnel in order for the NHRP Redirect to be triggered, which is necessary so that the spoke-to-spoke tunnels build properly. Rather than issuing "no no ip next-hop-self eigrp AS_NUMBER," you will want to enable next-hop-self with "ip next-hop-self eigrp AS_NUMBER" on the Hub's tunnel interfaces, or using the respective commands in your EIGRP named-mode configuration.

-Frank

[Frank DeNofa]

A question from the webcast Q&A:

Should we use IKEv1 or IKEv2 with DMVPN?

Either IKEv1 or IKEv2 will work for DMVPN. There are benefits to both options, although IKEv2 was designed to be the successor to IKEv1. Googling the topic will return many non-Cisco articles which compare the two protocols. The RFCs are a good place to start as well.

RFC 4109: https://tools.ietf.org/html/rfc4109

RFC 5996: https://tools.ietf.org/html/rfc5996

-Frank

[Frank DeNofa]

A question from the webcast Q&A:

Will phase 3 behind nat using a vrf establish a route wih another remote site?

Yes, this is something which is entirely possible. When using VRF-lite, all of our VRFs only locally significant. Therefore, if Spoke1 is configured with an iVRF and fVRF, it will have no impact on how Spoke2 handles its traffic. As long as the VRF-concerned crypto and routing configuration is correct, the dynamic spoke-to-spoke issues should build without issue.

-Frank

[Frank DeNofa]

A question from the webcast Q&A:

Is NAT T still required when using IKEv2?

Yes, NAT-traversal will be used whenever ISAKMP (IKEv1 or IKEv2) detects NAT in the path. This will encapsulate all ESP packets within UDP.

-Frank