Showing results for 
Search instead for 
Did you mean: 

Ask the Expert- Dynamic Multi-point VPN on Cisco routers: Best Practices & Configuration

Cisco Moderador
Community Manager
Community Manager

This topic is a chance to discuss more about the best practices to configure, deploy and troubleshoot Dynamic Multi-point VPN (DMVPN) on Cisco Routers. The session provides insight about the base components involved in DMVPN and its different phases of deployment. It focus particularly on the basic configuration of its phases and on the best practices required when using DMVPN on Cisco routers.

Dynamic Multipoint VPN is a Cisco IOS/IOS-XE Software solution for building scalable IPsec Virtual Private Networks (VPNs). This routing technique is used to build Virtual Private Networks with multiple sites without having to statically configure all devices, DMVPN essentially creates a mesh VPN topology over the public or private WAN or Internet. Its deployments include mechanisms such as GRE tunneling and IPsec encryption with Next Hop Resolution Protocol (NHRP) routing, they are designed to reduce administrative burden and provide reliable dynamic connectivity between sites.


To participate in this event, please use theJoin the Discussion : Cisco Ask the Expertbutton below to ask your questions


Ask questions from Monday November 26th to Friday 14th of December, 2018


Featured expert

Leo-Davila.JPGLeonardo Peña Davila is a Network Engineer with over 15 years of experience on network design, enterprise networks, administration and support. He works as Network Engineer on Microplus Computo y Servicios in Mexico. Before he worked on Petroleos de Venezuela as Network Engineer administrating and managing a diverse amount of complex networks, from WLC, ACS, ASA to CUCM. Leonardo obtained his first Cisco CCNA certification in 2002 and he has a CCNP R&S as well, he is passionate about his profession and committed to keep up-to-date with new technology developments. He is interested on Data Center technology, particularly on Nexus switches, APIC, APIC-EM, VMware virtualization, ESX, ESXi, UCS and Network Programmability.


Leonardo might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Security  community.

Find other events  


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

20 Replies 20

Level 1
Level 1



many thanks for the opprtunity to ask some questions about DMVPN design .


1. Recommended Routing-Protocol :

Is there a recommendation which protocol to choose in a DMVPN Ph3 environment ?

I thought, EIGRP and BGP would be the weapon of choice.

Some say , OSPF is possible, but not recommended ( configuration and troubleshooting might be challenging ).

My knowledge is taken from some elder Cisco-docs , dont know if this is still valid.


2. Best Practice during a Migration :

2.a Tunnel Protection , Migration from IKEv1 to IKEv2

We are trying to migrate an existing DMVPN Deployment. One step will be the replacement of the EOL-Routers step by step.

Since we have to change the configuartion during this replacement ( IOS to IOS-XE e.g. ) , we would like to move to IKEv2 in general.

What is the recommendation in such a "mixed environment" ?


Is it possibe to migrate without changing the topology , means can i use IKEv1 and IKEv2 under the same tunnel-interface ?

If this is not possible, do i have to build seperate topologies for IKEv1 and IKEv2 ? ( diffenrent tunnel-interfaces , different hubs etc. ).


Many thanks in advance.



Hi Cristhian thanks for your question:


Generally you would use the same routing protocol over DMVPN that you use in the rest of your network. As you mentioned EIGRP and BGP are the best choices. EIGRP being an advanced distance vector protocol matches really well with DMVPN network topologies. EIGRP has good scalability, reasonably fast convergence, good metric control (Automatic metric increase per DMVPN hop), can be used to control load-balancing of spoke - hub traffic, etcetera. 


BGP, specifically iBGP, runs well over DMVPN, but is more complicated to setup to have it act more like an IGP than an EGP. Good scaling but with slower convergence, good metric control.


OSPF can run over DMVPN, but lower scaling and Area 0 issues can complicate the network. More difficult metric control, can only change metrics, filter or summarize at area boundaries, automatic metric increase per DMVPN hop, etcetera. 


DMVPN supports all routing protocols, except ISIS but when choosing an IGP for use over a DMVPN infrastructure, using a vector protocol such as EIGRP is a best choice.



For migration the key for success is to have a good documentation and follow a plan step by step. If you are able to build a separate topology you should do that.  By using IKEv2 you can have additional capabilities that maybe you can adapt to your environment. IKEv2 allows you scalability by using Proposals which automatically expand the different combinations of Integrity, Encryption and Group. Also, increase security by using more secure algorithms  




Hi Leonardo,


many thanks for the detailed explanations , makes sense to me.


Best Regards,





1) best recommended routing protocol by cisco is bgp, simply because bgp allow You to configure hub as " no touch device" so hub learns its peers dynamically by using " bgp listen range ... "  command. 


2) You can migrate to ikev2 by using same dmvpn tunnel, tunnel protection is done by ipsec profile to perform encryption for traffic which goes over tunnel(" tunnel protection ipsec profile ... "). You can migrate it by doing following steps:


a) creating new ip sec profile which is using ikev2 on all hub and spokes(this can be done without traffic disruption)

b) apply under tunnel interface: tunnel protection ipsec profile ... on hub thirst(after timers expire for phase 1 and 2, it will break connectivity, You can modify timers on both hub and spokes to make it longer for smoother migration)

c) apply under tunnel interface: tunnel protection ipsec profile ... on all spokes

d) reset hub tunnel interface

e) reset spokes tunnel interface


Migration procedure using same tunnel interface will cause break in the connectivity so it is better to perform that change in maintenance window. Alternatively if You have additional public Ip address, You can create new tunnel interface on all hub and spokes, but still it will cause some network disruption when doing rerouting for LAN to use new tunnel however disruption will be considerable lower  than migrating using same tunnel. 


Migration for LAN to new tunnel can be done by using protocols with higher AD or floating static routes with higher AD - it depends what routing is used(so You can prepare it earlier without breaking connectivity) - it might help to migrate smoother.


Hope it helps


Good luck :) 

Level 1
Level 1



i am just scratching my head about the following behaviour, and i am not sure if i understood it right.


When i am using eigrp summaries at my spokes , the next-hop for the summary route is always the NHRP-Address of the Hub.

Dynmic spoke-to-spoke tunnels are succesfully created, connectivity is there.

NHRP injects "NHRP" routes for the routes that are "summarized" , using the next-hop of the spoke that advertises the summary. Looks fine, i think thats the expected bahaviour.


But why does the hub does not "redirect" queries for the summary route to the "real" Spoke-Address ?


I have a DMVPN Topology with EIGRP used as routing protocol.


Tunnel 2 with IPs used 10.xx.y.0/24 , Hub uses 10.xx.y.254 , Spoke1 uses 10.xx.y.8 , Spoke uses 10.xx.y.111


Spoke1 "hosts" various subnets out of the 10.222.x.x/16 range. Spoke1 asdvertises a EIGRP summary


Routing table from SPOKE2 :

<--- Summary w/ Hub as next-hop
D [90/10296320] via 10.xx.y.254, 01:44:43, Tunnel2 <--- Summary w/ Hub as next-hop

! <-- summarized routes w/ Spoke1 as next-hop , injected by NHRP

H [250/255] via 10.xx.y.8, 01:05:14, Tunnel2 
H [250/255] via 10.xx.y.8, 01:05:17, Tunnel2
H [250/255] via 10.xx.y.8, 01:05:18, Tunnel2
H [250/255] via 10.xx.y.8, 01:05:07, Tunnel2
H [250/255] via 10.xx.y.8, 01:05:16, Tunnel2
H [250/255] via 10.xx.y.8, 01:04:26, Tunnel2


I wonder if this the expected behaviour ?


Bst Regards,



To form spoke to spoke tunnels in Phase 3 we combine summarization and exclude process switching. In Phase 3 spokes don’t need full routing table, In DMVPN Phase III We will get the specific route via NHRP.

In this Phase as well as in Phase II, we want the traffic exchange between Spokes is done directly without going through the Hub, however, in Phase III will not change the behavior of the routing protocol (EIGRP), but we will use the NHRP Protocol.

An ip nhrp redirect message indicates that the current route to the destination is not the best, so the receiver of the message (Spoke) should find a better route for that destination.

ip nhrp shoortcut  Tells the router to accept ip nhrp redirect messages and rewrites the new CEF entry. (Cisco Express Forwarding entry).

If we look at the routing table in a Spoke, we will notice that the next hop for all routes will be the Hub, however, an NHRP Cache will be created that tells Hub a better route for each destination.



R2 – R3 & R4


interface Tunnel1

ip address

ip nhrp map

ip nhrp map multicast

ip nhrp network-id 1

ip nhrp nhs

ip nhrp shortcut

tunnel source

tunnel mode gre multipoint


If we look at the routing table on Spoke (R2):

R2#sh ip route eigrp

Gateway of last resort is to network is variably subnetted, 5 subnets, 2 masks

D [90/27008000] via, 01:03:01, Tunnel1

D [90/28288000] via, 01:03:01, Tunnel1

D [90/28288000] via, 01:03:01, Tunnel1


Now let’s take a look at:

R2#sh ip nhrp via

Tunnel1 created 00:00:01, expire 01:59:58

Type: dynamic, Flags: router rib nho

NBMA address: via

Tunnel1 created 00:00:12, expire 01:59:47

Type: dynamic, Flags: router rib nho

NBMA address:


If we make a traceroute from R2 to R4 we’ll see the following :



Type escape sequence to abort.

Tracing the route to

VRF info: (vrf in name/id, vrf out name/id)

1 0 msec 1 msec 0 msec


On top of that, in Phase 3 we can summarize:




interface Tunnel1

ip address

no ip redirects

no ip split-horizon eigrp 1

ip nhrp map multicast dynamic

ip nhrp network-id 1

ip nhrp redirect

ip summary-address eigrp 1

tunnel source Ethernet0/0

tunnel mode gre multipoint



If we see the routing table on Spokes (R2, R3, R4)

R2#sh ip route eigrp is variably subnetted, 4 subnets, 3 masks

D [90/27008000] via, 00:00:52, Tunnel1

If we do a traceroute from R2 to R4 we’ll see that communication between them is direct without passing by the Hub.


Type escape sequence to abort.

Tracing the route to

VRF info: (vrf in name/id, vrf out name/id)

1 2 msec 6 msec 5 msec




Level 1
Level 1



I currently have a DMVPN deployment using IKEv2 with keyrings and PSK for the tunnel encryption.  


Currently my keyring is configured like:

crypto ikev2 keyring DMVPN-keyring
 peer ANY
  pre-shared-key secretkey


I haven't found any good documentation or best practices for key rotation.  Is there anything that you could point me towards or advise?  I'd like to be able to rotate to new keys with minimal to no impact.  

Hello leonardo


I need Config example regarding 2 DMVPN HUB sits in DMZ behind Cisco ASA




Hi Ibrahim

I found an interesting example on cisco forum, Here the link.




thanks Leonardo

Level 4
Level 4

Hello Leonardo - How are you. Thanks for sharing ideas, expertise solutions and answer to your queries


We are planning to migrate Point to Point GRE tunnels to DMVPN or MGRE tunnels where Datacenter(Hub) router will have one tunnel and remote sites will have GRE tunnel to my Hub Router.


I current situation we have the flexibility of shutting down a GRE Tunnel of a remote site (Example: Chicago Office) from Hub itself by getting into the respective tunnel of Chicago and give command "shutdown" and later by "no shutdown" I can bring up the site. This requirement arises during troubleshooting 


What is the way I can shutdown a remote office Tunnel from Hub Router if I migrate to DMVPN or mGRE tunnel?





Level 1
Level 1

I have an issue with spoke-to-spoke VPNs the VPNs work well spoke-hub-spoke, and the sites directly connected to the internet work well spoke-to-spoke, the issue is with sites that sit on private IP addresses which either are natted to publics via a 3G router or similar. The site DMVPN routers which are behind privates can ping the remote sites that they can't form a spoke-to-spoke VPN with.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: