11-23-2018 01:40 PM - edited 03-12-2019 05:32 AM
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 thebutton below to ask your questions
Ask questions from Monday November 26th to Friday 14th of December, 2018
Featured expert
Leonardo 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 https://community.cisco.com/t5/custom/page/page-id/Events?categoryId=technology-support
**Helpful votes Encourage Participation! **
Please be sure to rate the Answers to Questions
11-26-2018 05:45 AM
Hi,
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.
/Christian.
11-26-2018 10:29 PM
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
Regards
Leonardo
11-27-2018 03:16 AM
Hi Leonardo,
many thanks for the detailed explanations , makes sense to me.
Best Regards,
12-14-2018 12:16 AM
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 :)
11-27-2018 03:41 AM
Hi,
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 10.222.0.0/16.
Routing table from SPOKE2 :
! <--- Summary w/ Hub as next-hop
D 10.222.0.0/16 [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 10.222.20.0/24 [250/255] via 10.xx.y.8, 01:05:14, Tunnel2
H 10.222.22.0/24 [250/255] via 10.xx.y.8, 01:05:17, Tunnel2
H 10.222.30.0/24 [250/255] via 10.xx.y.8, 01:05:18, Tunnel2
H 10.222.31.0/24 [250/255] via 10.xx.y.8, 01:05:07, Tunnel2
H 10.222.40.0/24 [250/255] via 10.xx.y.8, 01:05:16, Tunnel2
H 10.222.80.0/24 [250/255] via 10.xx.y.8, 01:04:26, Tunnel2
SPOKE2#
I wonder if this the expected behaviour ?
Bst Regards,
/Christian
11-29-2018 06:23 PM
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 192.168.1.2 255.255.255.0
ip nhrp map 192.168.1.1 190.1.1.1
ip nhrp map multicast 190.1.1.1
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
ip nhrp shortcut
tunnel source 190.1.2.2
tunnel mode gre multipoint
end
If we look at the routing table on Spoke (R2):
R2#sh ip route eigrp
Gateway of last resort is 190.1.2.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27008000] via 192.168.1.1, 01:03:01, Tunnel1
D 10.1.3.0/24 [90/28288000] via 192.168.1.1, 01:03:01, Tunnel1
D 10.1.4.0/24 [90/28288000] via 192.168.1.1, 01:03:01, Tunnel1
Now let’s take a look at:
R2#sh ip nhrp
10.1.3.0/24 via 192.168.1.3
Tunnel1 created 00:00:01, expire 01:59:58
Type: dynamic, Flags: router rib nho
NBMA address: 190.1.3.3
10.1.4.0/24 via 192.168.1.4
Tunnel1 created 00:00:12, expire 01:59:47
Type: dynamic, Flags: router rib nho
NBMA address: 190.1.4.4
….
If we make a traceroute from R2 to R4 we’ll see the following :
R2#traceroute 10.1.4.4
Type escape sequence to abort.
Tracing the route to 10.1.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.4 0 msec 1 msec 0 msec
On top of that, in Phase 3 we can summarize:
R1
!
interface Tunnel1
ip address 192.168.1.1 255.255.255.0
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 10.0.0.0 255.0.0.0
tunnel source Ethernet0/0
tunnel mode gre multipoint
end
If we see the routing table on Spokes (R2, R3, R4)
R2#sh ip route eigrp
…
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
D 10.0.0.0/8 [90/27008000] via 192.168.1.1, 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.
R2#traceroute 10.1.4.4
Type escape sequence to abort.
Tracing the route to 10.1.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.4 2 msec 6 msec 5 msec
R2#
12-06-2018 09:03 AM
Hi,
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
address 0.0.0.0 0.0.0.0
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.
12-07-2018 07:32 AM
Hello leonardo
I need Config example regarding 2 DMVPN HUB sits in DMZ behind Cisco ASA
Thanks
12-08-2018 05:23 PM
Hi Ibrahim
I found an interesting example on cisco forum, Here the link.
Regards
Leonardo
12-09-2018 03:47 AM
thanks Leonardo
12-08-2018 05:11 PM
Hi daytonweeks00
Take a look at the following links, you can find very interesting information about configuring IKEv2
https://clnv.s3.amazonaws.com/2018/usa/pdf/BRKSEC-3001.pdf
https://clnv.s3.amazonaws.com/2017/usa/pdf/BRKSEC-3052.pdf
Hope this help
Regards
Leonardo
12-11-2018 09:31 AM
Hi daytonweeks00
Take a look at the following links, you can find very interesting information about configuring IKEv2
https://clnv.s3.amazonaws.com/2018/usa/pdf/BRKSEC-3001.pdf
https://clnv.s3.amazonaws.com/2017/usa/pdf/BRKSEC-3052.pdf
Hope this help
Regards
Leonardo
12-14-2018 12:25 AM
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?
regards,Sairam
12-14-2018 03:11 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide