DMVPN with IKEv1 vs IKEv2: Configuration and Migration

Every DMVPN carries IPsec, and every IPsec deployment sits on one of two key-exchange protocols: IKEv1, the original from 1998, or IKEv2, its 2005 replacement. Most networks still run IKEv1 because it works and nobody wanted to touch a working VPN. But IKEv2 is faster to negotiate, cleaner to configure, more resilient, and it is where everything is heading.

This article configures both on the same DMVPN in a CML lab, shows the real SA output from each side by side, and walks the migration - which, it turns out, is a single-line profile swap. For the fundamentals, start at the complete DMVPN guide.

Why IKEv2 is better

IKEv1 configuration

IKEv1 uses ISAKMP policies. The tunnel protection references an IPsec profile that has no explicit IKE binding - IKEv1 is the default:

crypto isakmp policy 10
 encryption aes 256
 hash sha
 authentication pre-share
 group 14
 lifetime 86400
!
crypto isakmp key PingLabzIKEv1 address 0.0.0.0
!
crypto ipsec transform-set TS-IKEV1 esp-aes 256 esp-sha-hmac
 mode transport
!
crypto ipsec profile IPSEC-IKEV1
 set transform-set TS-IKEV1
!
interface Tunnel0
 tunnel protection ipsec profile IPSEC-IKEV1

IKEv1 verification

HUB1#show crypto isakmp sa
dst             src             state          conn-id status
100.64.1.1      100.64.11.1     QM_IDLE           1006 ACTIVE
100.64.1.1      100.64.12.1     QM_IDLE           1007 ACTIVE
100.64.1.1      100.64.2.1      QM_IDLE           1005 ACTIVE

The tell of a healthy IKEv1 SA is QM_IDLE (Quick Mode idle - phase 1 complete, phase 2 negotiated, ready). The detail:

HUB1#show crypto isakmp sa detail | include 100.64.11.1
1006  100.64.1.1  100.64.11.1  ACTIVE aes  sha    psk  14 23:58:46

AES, SHA, PSK, DH group 14, lifetime counting down from 24 hours. And traffic is flowing through it:

HUB1#show crypto ipsec sa peer 100.64.11.1 | include transform|pkts encaps|pkts decaps
    #pkts encaps: 29, #pkts encrypt: 29, #pkts digest: 29
    #pkts decaps: 27, #pkts decrypt: 27, #pkts verify: 27
        transform: esp-256-aes esp-sha-hmac ,

IKEv2 configuration

IKEv2 replaces the flat ISAKMP policy with a keyring and a profile - more objects, but cleaner separation of concerns:

crypto ikev2 keyring KR
 peer ANY
  address 0.0.0.0 0.0.0.0
  pre-shared-key PingLabzIKEv2
!
crypto ikev2 profile IKEV2-PROF
 match identity remote address 0.0.0.0
 authentication local pre-share
 authentication remote pre-share
 keyring local KR
!
crypto ipsec transform-set TS-IKEV2 esp-aes 256 esp-sha256-hmac
 mode transport
!
crypto ipsec profile IPSEC-IKEV2
 set transform-set TS-IKEV2
 set ikev2-profile IKEV2-PROF          <-- this line is what makes it IKEv2
!
interface Tunnel0
 tunnel protection ipsec profile IPSEC-IKEV2

The one line that makes it IKEv2 rather than IKEv1 is set ikev2-profile in the IPsec profile. Without it, IOS falls back to IKEv1. And note authentication local and authentication remote are separate directives - that is the asymmetric authentication capability, even though we use PSK on both sides here.

IKEv2 verification

HUB1#show crypto ikev2 sa
Tunnel-id Local                 Remote                fvrf/ivrf            Status
2         100.64.1.1/500        100.64.11.1/500       none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/28 sec
      Local spi: A0F41498A3310CEE       Remote spi: B2BE8D43E865239F

The IKEv2 SA state is READY, and the output is richer: it explicitly shows the PRF (pseudo-random function) as a separate field, the DH group, and separate Auth sign / Auth verify directions - reflecting IKEv2's cleaner, more explicit design.

Side by side

Both of these ran on the same DMVPN, carrying the same traffic, in the same lab. The only thing that changed between them was which IPsec profile the tunnel referenced.

The migration is a profile swap

Here is the practical payoff. Migrating a DMVPN from IKEv1 to IKEv2 does not mean rebuilding the tunnels. Both IPsec profiles can coexist on the router; you just change which one the tunnel references:

interface Tunnel0
 tunnel protection ipsec profile IPSEC-IKEV2    <-- was IPSEC-IKEV1
% Shutting down Tunnel0 interface due to IPsec tunnel protection modification.
% Please run "no shutdown" after config change to bring up the interface.

The catch: IOS XE forces a tunnel bounce when you change the protection profile. It shuts the tunnel and makes you bring it back up. That is a brief outage on that tunnel, so plan the migration in a maintenance window and do it hub by hub, spoke by spoke.

interface Tunnel0
 shutdown
 no shutdown

After the bounce, all SAs re-form under the new suite. In the lab we migrated the entire cloud from IKEv2 to IKEv1 (and could reverse it identically) purely by swapping the referenced profile and bouncing each tunnel.

Migration order

1. Pre-stage both profiles on every device. The IKEv2 keyring, profile, transform-set and IPsec profile can all sit there unused while IKEv1 is live.
2. Migrate the hubs first, one at a time, so at least one hub always has a working profile a spoke can match. Because the tunnel bounces, doing both hubs at once would drop every spoke.
3. Then the spokes, in batches. A spoke on IKEv2 can still reach a hub on IKEv2; do not leave a spoke stranded on a suite no hub offers.
4. Verify each device shows the new SA type (READY for IKEv2) before moving on.

The important sequencing rule: never leave a spoke and its hub on different IKE versions. They will not negotiate. Migrate a hub, then the spokes that use it, keeping each spoke-hub pair on the same version throughout.

Which to use

• New DMVPN? IKEv2, always. There is no reason to start on IKEv1 in 2026.
• Existing IKEv1 DMVPN, working fine? Plan a migration to IKEv2 - the operational and security benefits are real - but there is no fire. Do it in windows, hub-first.
• Mixed-vendor or legacy peers? Verify IKEv2 support on both ends first. Very old gear may only speak IKEv1, and a mismatch simply will not come up.

Key takeaways

• IKEv2 is faster to negotiate (4 messages vs 6), has built-in dead-peer detection, better NAT handling, and asymmetric authentication. Use it for anything new.
• IKEv1 uses crypto isakmp policy + key; a healthy SA shows QM_IDLE in show crypto isakmp sa.
• IKEv2 uses crypto ikev2 keyring + profile; a healthy SA shows READY in show crypto ikev2 sa, with an explicit PRF field.
• The one line that selects IKEv2 is set ikev2-profile in the IPsec profile. Omit it and IOS uses IKEv1.
• Migration is a profile swap on the tunnel - but IOS XE bounces the tunnel when you change the protection profile, so do it in a window.
• Migrate hub-first, one device at a time, and never leave a spoke and its hub on different IKE versions - they will not negotiate.

Next: MPLS and DMVPN together - choosing and combining enterprise transports. The full cluster index lives on the DMVPN pillar.