Updating DMVPN encryption protocols

[johnplizarazo]

Hello, I am looking for advice on updating our DMVPN hub and spoke routers with new encryption and hashing protocols. I'd like to update them to:

#crypto ipsec transform-set TSET2-new esp-aes 256 esp-sha-hmac

My main question is, is there a way to automatically have the spokes renegotiate their tunnels using the new transform set and and ipsec profile that has been added? The steps below are what I have so far:

1. Adding the below configuration to hub and spoke routers, creating a new transform set

   #crypto ipsec transform-set TSET2-new esp-aes 256 esp-sha-hmac
   #  mode tunnel

2. Adding the below configuration to hub and spoke routers, creating a new ipsec profile

   #crypto ipsec profile dmvpn-aes-new
   #  set transform-set TSET2-new

Here’s where I’m hoping I can automatically have spoke routers switch over to the new transform set, if I issue the commands below on the hub, will the spokes automatically switch over to the new transform set? If not is there a way to issue a command on the hub that will force the spokes to reconnect using the new transform set and ipsec profile on the DMVPN hub?

3. Removing the old transform set and ipsec profile from the hub

   #crypto ipsec transform-set TSET1-old esp-3des esp-sha-hmac
   #no crypto ipsec profile dmvpn-old

4. Issue command on hub to force spokes to renegotiate tunnels

   #clear dmvpn-old session interface tunnel1
   #clear dmvpn-old session interface tunnel2
   #clear crypto sa
   #clear crypto isakmp

If it's not possible to have the spokes automatically switch over, what would be the best way to update 20+ DMVPN devices?

Is there anything else I should consider when making this change? Thanks for any help!

Hub configuration:

!
crypto ipsec transform-set TSET1-old esp-3des esp-sha-hmac 
mode tunnel
!
crypto ipsec profile dmvpn-old
set transform-set TSET1-old
!
interface Tunnel1
...
tunnel protection ipsec profile dmvpn-old shared
!

Spoke configuration:

!
crypto ipsec transform-set TSET1-old esp-3des esp-sha-hmac 
mode tunnel
!
crypto ipsec profile dmvpn-old
set transform-set TSET1-old 
!
interface Tunnel1
...
tunnel protection ipsec profile dmvpn-old shared
!

[Francesco Molino]

Hi

You can't remove the old profile and get the tunnel taking the new profile without configuring it.

You need by anyways to apply the new profile under the tunnel interface configuration.

Here you don't have a lot of solutions.

Do you have ssh access to all routes over the wan interface? If so, you can schedule a maintenance window and push all configs using a script.

If you have dynamic routing on all sites, you can create a new dmvpn cloud (new tunnel interfaces) using the new profile. When this new cloud is up and running, you can shutdown old tunnels. The impact will be less if all routing learned new ip addresses.

[johnplizarazo]

Thank you for the suggestion, setting up a new DMVPN cloud alongside the existing one seems to be the safest way to configure this! We do have dynamic routing enabled between all sites using EIGRP.

This seems like a really interesting idea. I guess there would be no problem setting up multiple DMVPN tunnels on single source interface? We currently have a primary and secondary tunnel for most sites so this method would add two more.

Do you know if there would be any issue with conflicting configurations on the hub or spoke after adding a second DMVPN cloud?

[Francesco Molino]

Adding a new cloud which means network of is different from the other one you won't have any issues. 

You already have 2 tunnels. The second one you called backup, how is it configured?

When I'll have your config for those secondary tunnel i will validate or not if you can do the following. Depending on their config you can maybe leverage The second one as active with the new profile and when they'll be up you will change the first tunnel.

Can you share your tunnel config for hub and 1 spoke to see those 2 tunnels?

[johnplizarazo]

Ahhh that's an excellent idea too. Configs for our hub and spoke are below. We have the primary tunnel going to our main datacenter, and secondary going to out backup site.

We actually have two primary tunnels headed to our main datacenter (most locations only use one tunnel, locations with two ISP's use both I believe.)

Spoke:

!
crypto ipsec transform-set TSET1-OLD esp-3des esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile dmvpn-OLD
 set transform-set TSET1-OLD
!
interface Tunnel10
 description Primary Site DMVPN
 bandwidth 500
 ip address 172.16.1.10 255.255.255.0	        #Spoke private IP
 no ip redirects
 ip mtu 1400
 ip nhrp authentication password
 ip nhrp map multicast dynamic
 ip nhrp map 172.16.1.1 1.1.1.1			#Hub private and public IP
 ip nhrp map multicast 1.1.1.1
 ip nhrp network-id 100
 ip nhrp holdtime 600
 ip nhrp nhs 172.16.1.1				#Hub private IP
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile dmvpn-OLD shared
!
interface Tunnel30
 description Secondary Site DMVPN Tunnel30
 bandwidth 120
 ip address 172.16.3.10 255.255.255.0          #Spoke private IP
 no ip redirects
 ip mtu 1400
 ip nhrp authentication password
 ip nhrp map multicast dynamic
 ip nhrp map 172.16.3.1 3.3.3.3                #Hub private and public IP
 ip nhrp map multicast 3.3.3.3
 ip nhrp network-id 300
 ip nhrp holdtime 600
 ip nhrp nhs 172.16.3.1                        #Hub private IP
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 300
 tunnel protection ipsec profile dmvpn-OLD shared
!

Primary Site Hub:

!
crypto ipsec transform-set TSET1-OLD esp-3des esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile dmvpn-OLD
 set transform-set TSET1-OLD
!
interface Tunnel10
 description Primary Site DMVPN Tunnel10
 bandwidth 20480
 ip address 172.16.1.1 255.255.255.0           #Hub private IP
 no ip redirects
 ip mtu 1400
 no ip next-hop-self eigrp 1
 no ip split-horizon eigrp 1
 ip nhrp authentication password
 ip nhrp map multicast dynamic
 ip nhrp network-id 100
 ip nhrp holdtime 600
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile dmvpn-OLD shared
!
interface Tunnel20 
 description Primary Site DMVPN Tunnel20
 ip address 172.16.2.1 255.255.255.0           #Hub private IP
 no ip redirects
 ip mtu 1400
 ip nhrp authentication password
 ip nhrp map multicast dynamic
 ip nhrp network-id 200
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
 tunnel key 200
 tunnel protection ipsec profile dmvpn shared
!

Secondary Site Hub:

!
crypto ipsec transform-set TSET1-OLD esp-3des esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile dmvpn-OLD
 set transform-set TSET1-OLD
!
interface Tunnel10
 description Secondary Site DMVPN Tunnel30
 bandwidth 20480
 ip address 172.16.3.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip next-hop-self eigrp 1
 no ip split-horizon eigrp 1
 ip nhrp authentication password
 ip nhrp map multicast dynamic
 ip nhrp network-id 300
 ip nhrp holdtime 600
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
 tunnel key 300
 tunnel protection ipsec profile dmvpn-OLD shared
!

[Francesco Molino · Accepted solution]

These are different clouds then modify one, make sure it's up and running and routing is ok then modify the primarily. Down time will be very very short doing that way

[johnplizarazo]

Thanks for the suggestion! Will be trying it out. On another note, would both DMVPN clouds share the same routes? I'm wondering how I could verify that the two clouds are the same in terms of routing.

[Francesco Molino]

Based on your config, there're all part of EIGRP AS 1. If you issue show ip eigrp neighbor from HUB you can see the peering with spokes (if you kept eigrp config as its basic config). Or if you issue show ip route eigrp, you should see Tunnel 10 subnets into RIB.

[Joseph W. Doherty]

Although on both ends of a DMVPN tunnel, you should be able to "rank" which IPSec profile will be used first, I recall(?) an existing session will continue to use what it's using until it has to start a new session. I.e. shutting the tunnel or clearing the crypto session would be required.