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.

 

[Hamzah Kardame]

A question from the webcast Q&A:

 Is it needed for redundant hubs to have a tunnel between each other? If yes, why?

This really depends on the network design; If the hubs are serving/protecting the same LAN(s) at the head office or DC and if they are serving the same set of spokes (meaning your spokes are configured to connect to both hubs), then a tunnel between the hubs themselves wouldn't be required.

However, if the hubs are serving/protecting different networks altogether or if the spokes have been segregated such that one group connects to hub1 and the other to hub2, then we will need a tunnel between the hubs to allow for complete end-to-end connectivity.

-Hamzah.

[Hamzah Kardame]

A question from the webcast Q&A:

Can we use phase 3 with summarization in a 3 hub deployment across the internet, with MPLS in all sites as a primary path?

Yes, this is possible. The MPLS path can be monitored and in the event of a failure, the DMVPN tunnels can be used as the backup link. The DMVPN tunnels could remain active over the internet transport links and you would need to alter the underlying routing protocol metrics so that the MPLS path is preferred and the corresponding 3 DMVPN hubs would remain as backup paths; this would allow for a quick switchover in the event of a failover to the DMVPN tunnels.

-Hamzah.

[ken730529]

Why the command "no ip redirects" is required on the tunnel interface of hub and spoke router?

What if the hub router goes down while the packet is being forwarded between spoken router?

[Frank DeNofa]

Ken,

While it is not specific to DMVPN/GRE, "no ip redirects" prevents the router from sending ICMP redirects on that interface. The following resources go into this a bit more.

http://www.cisco.com/c/en/us/td/docs/ios/12_2/ipaddr/command/reference/fipras_r/1rfip2.html#wp1019389

https://supportforums.cisco.com/discussion/9246441/no-ip-redirects-command

That said, "ip nhrp redirects" is required on your Hub router's tunnel interface. Similar to ICMP redirects which are triggered when packets ingress and egress the same interface, NHRP redirects are triggered when a packet ingress and egress the same NHRP network, as specified by the "ip nhrp network-id" command. This redirect is what triggers the Spoke to Spoke tunnel negotiation.

To answer your second question, if a Spoke to Spoke tunnel is built and the tunnel to the Hub router goes down, the Spoke to Spoke tunnel will stay up and remain functional until the routing protocol between the Hub and Spoke goes down. While NHRP does install a route in the route table (either via NHO or an H route), it relies on the "parent" route learned via our routing protocol for it to function. If we lose the parent route, the dependent NHO and H routes will be lost.

-Frank

[Daniel Maloney]

Hello! Thank you for this very interesting webinar.

For me something is not clear in the section where Frank DeNofa talks about General Best Practices. He said that routing protocol hello is not also supported with tunnel protection? Can you please explain what do you mean.. I didn't get it..

[Frank DeNofa · Accepted solution]

Daniel,

I apologize if I was unclear. The intended message is that GRE keepalives are unsupported when configured in conjunction with tunnel protection, as discussed here: http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive.html

I was attempting to make a point that in addition to GRE keepalives be unsupported, they are largely unnecessary as we have ISAKMP keepalives and periodic routing protocol Hellos to maintain connectivity and detect failures.

Hopefully this clears things up,

Frank

[Daniel Maloney]

Thank you very much!