Skip to content
Log in Sign up My account

DMVPN phase 3 with IKEv2: a step-by-step lab

This lab builds a DMVPN phase 3 network on IOS XE with one hub and two spokes over a simulated internet. You will configure mGRE tunnels, NHRP registration, ip nhrp redirect and ip nhrp shortcut, an IKEv2 profile with pre-shared keys, an IPsec profile on the tunnels, and EIGRP with summarization at the hub. You will then prove that spoke-to-spoke traffic moves to a direct shortcut tunnel, and work through the failures you are most likely to hit. Any IOS XE image works: CSR1000v, Catalyst 8000V or IOL-style images in your emulator. See lab platforms if you have not picked one, or the CCNP lab setup page.

Topology and addressing

Three sites connect through one router that plays the internet. The "internet" router only has connected routes and a default-free view of the world: it knows the three underlay subnets and nothing else. Every tunnel packet must cross it, which is what you want.

graph TB
    subgraph NET["Simulated internet"]
        ISP["ISP router"]
    end
    HUB["HUB<br/>Gi0/0 203.0.113.1<br/>Tunnel0 10.0.0.1<br/>LAN 192.168.1.0/24"]
    S1["SPOKE1<br/>Gi0/0 198.51.100.1<br/>Tunnel0 10.0.0.2<br/>LAN 192.168.10.0/24"]
    S2["SPOKE2<br/>Gi0/0 192.0.2.1<br/>Tunnel0 10.0.0.3<br/>LAN 192.168.20.0/24"]
    HUB --- ISP
    S1 --- ISP
    S2 --- ISP
Device Underlay (NBMA) address Tunnel address LAN
HUB 203.0.113.1/30 10.0.0.1/24 192.168.1.0/24
SPOKE1 198.51.100.1/30 10.0.0.2/24 192.168.10.0/24
SPOKE2 192.0.2.1/30 10.0.0.3/24 192.168.20.0/24

The ISP router uses the other end of each /30 (203.0.113.2, 198.51.100.2, 192.0.2.2). Each of the three routers also needs a default route (or a route to the other two underlay subnets) pointing at the ISP router. Confirm underlay reachability before you configure anything else:

SPOKE1# ping 203.0.113.1 source GigabitEthernet0/0
SPOKE1# ping 192.0.2.1 source GigabitEthernet0/0

Tip

Most DMVPN problems are really underlay problems. If the tunnel source cannot reach the other tunnel source, nothing above it will work. Always test with source set to the physical interface.

How phase 3 works

In phase 3 the hub stays in the control path and the spokes learn each other on demand.

  1. Each spoke registers its tunnel-to-NBMA mapping with the hub, the next hop server (NHS), using NHRP.
  2. The hub advertises a summary (or default route) to the spokes through the routing protocol. Spokes do not hold routes to each other's LANs.
  3. SPOKE1 sends traffic for SPOKE2's LAN to the hub, following the summary.
  4. The hub forwards the packet and sends an NHRP traffic indication (redirect) back to SPOKE1 because the packet entered and left the same mGRE interface.
  5. SPOKE1 sends an NHRP resolution request for the destination. The request is forwarded through the hub to SPOKE2, which answers directly to SPOKE1.
  6. SPOKE1 installs an NHRP shortcut (a more specific route plus an NHRP mapping) and builds a dynamic IPsec tunnel to SPOKE2. SPOKE2 does the same for the return direction.

The two commands that make this phase 3 are ip nhrp redirect on the hub and ip nhrp shortcut on the spokes. Without them you have phase 1 behavior.

Step 1: IKEv2 and IPsec

The IKEv2 pieces are the same on all three routers except for the keyring peer entries. The simplest keyring for a lab matches any peer address. In production, prefer per-peer keys or certificates, since one shared key across every site means that compromising one spoke compromises the lot.

crypto ikev2 keyring DMVPN-KEYS
 peer ANY
  address 0.0.0.0 0.0.0.0
  pre-shared-key local LabKey-Change-Me
  pre-shared-key remote LabKey-Change-Me
!
crypto ikev2 profile DMVPN-IKEV2
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local DMVPN-KEYS
!
crypto ipsec transform-set DMVPN-TS esp-aes 256 esp-sha256-hmac
 mode transport
!
crypto ipsec profile DMVPN-IPSEC
 set transform-set DMVPN-TS
 set ikev2-profile DMVPN-IKEV2

Notes on these lines:

  • match identity remote address 0.0.0.0 accepts any peer IP. A spoke behind NAT presents a different identity, so for NAT cases you would match on a FQDN or key ID instead.
  • mode transport saves the extra outer IP header because GRE already provides the tunnel. It also works through NAT-T in most cases. If you leave the default tunnel mode, both ends still agree, but you pay 20 more bytes per packet.
  • You do not need to define an IKEv2 proposal or policy. IOS XE ships default ones, which are used when you do not configure your own. If you want control over the algorithms, define a crypto ikev2 proposal and a crypto ikev2 policy and check the result with show crypto ikev2 proposal.

Step 2: hub tunnel

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp network-id 1
 ip nhrp map multicast dynamic
 ip nhrp redirect
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-IPSEC
  • ip nhrp network-id is locally significant but must be set for NHRP to run on the interface. Using the same value on every router keeps things tidy.
  • ip nhrp map multicast dynamic tells the hub to add each registering spoke to its multicast replication list, which lets EIGRP hellos reach the spokes.
  • no ip redirects turns off ICMP redirects. NHRP redirects are separate and are enabled by ip nhrp redirect.
  • MTU 1400 and MSS 1360 are conservative values that fit GRE plus ESP overhead on a 1500 byte underlay. Tune them for your real path.

Step 3: spoke tunnels

SPOKE1:

interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1 nbma 203.0.113.1 multicast
 ip nhrp shortcut
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-IPSEC

SPOKE2 is identical except for ip address 10.0.0.3 255.255.255.0.

The ip nhrp nhs ... nbma ... multicast form maps the hub's tunnel address to its public address and sends multicast to it in one line. Older documentation shows separate ip nhrp map, ip nhrp map multicast and ip nhrp nhs lines. They still work, but the single-line form is shorter.

Spokes use tunnel mode gre multipoint too, not point-to-point GRE with a destination. That is what lets them build direct tunnels to other spokes later.

Check registration on the hub:

HUB# show dmvpn

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 198.51.100.1            10.0.0.2    UP 00:01:12     D
     1 192.0.2.1               10.0.0.3    UP 00:01:05     D

Both spokes show as D (dynamic) with state UP. If a spoke is stuck in NHRP or IKE state, jump to the failures section.

Step 4: EIGRP with summarization

This lab uses classic EIGRP in AS 100. BGP works as well (see the note at the end of this section), but EIGRP keeps the config short.

Hub:

router eigrp 100
 network 10.0.0.0 0.0.0.255
 network 192.168.1.0 0.0.0.255
!
interface Tunnel0
 ip summary-address eigrp 100 192.168.0.0 255.255.0.0

Spokes (SPOKE1 shown; SPOKE2 uses 192.168.20.0):

router eigrp 100
 network 10.0.0.0 0.0.0.255
 network 192.168.10.0 0.0.0.255

The summary is the heart of phase 3 routing. The hub sends only 192.168.0.0/16 to the spokes, so each spoke has exactly one route toward the other spoke's LAN: via the hub. Because the spokes never receive each other's specific routes, there is no pre-built spoke-to-spoke path, and NHRP redirect has something to do.

Spokes still advertise their own LANs to the hub, so the hub holds the specific /24 routes. Check the spoke before any user traffic:

SPOKE1# show ip route eigrp
D     192.168.0.0/16 [90/26880256] via 10.0.0.1, 00:02:10, Tunnel0

Note

With a summary, you do not need no ip split-horizon eigrp 100 on the hub tunnel, because spokes are not relying on the hub to re-advertise each other's prefixes. Phase 2 designs need it. Phase 3 with summarization does not. A default route from the hub works the same way if you prefer that.

If you want BGP instead: run iBGP with the hub as a route reflector, or eBGP with a different AS per spoke, use neighbor statements for the spokes (or a dynamic bgp listen range 10.0.0.0/24), and have the hub advertise an aggregate with aggregate-address 192.168.0.0 255.255.0.0 summary-only. The phase 3 behavior is identical. It is the summarization that matters, not the protocol.

Step 5: verify the shortcut

Before any spoke-to-spoke traffic, SPOKE1 only knows the hub:

SPOKE1# show ip nhrp
10.0.0.1/32 via 10.0.0.1
   Tunnel0 created 00:03:20, never expire
   Type: static, Flags: used
   NBMA address: 203.0.113.1

Confirm only one IPsec peer exists:

SPOKE1# show crypto ikev2 sa

You should see a single SA to 203.0.113.1. Now generate traffic from SPOKE1's LAN toward SPOKE2's LAN. If you do not have hosts, source a ping from the LAN interface:

SPOKE1# traceroute 192.168.20.1 source 192.168.10.1

The first traceroute shows two hops: the hub (10.0.0.1), then SPOKE2 (10.0.0.3). Run it again after a few seconds:

Tracing the route to 192.168.20.1
  1 10.0.0.3 12 msec 8 msec *

One hop means the traffic now goes directly to SPOKE2. Check the evidence on SPOKE1:

SPOKE1# show ip nhrp shortcut
SPOKE1# show ip nhrp
SPOKE1# show dmvpn
SPOKE1# show ip route nhrp
SPOKE1# show crypto ikev2 sa

What you should see:

  • show dmvpn now lists SPOKE2's NBMA address (192.0.2.1) with attribute DT1 or DT2. D is dynamic and T1 marks a created spoke-to-spoke shortcut entry.
  • show ip nhrp has a dynamic entry for 10.0.0.3 and usually for the destination LAN prefix.
  • show ip route nhrp lists an H route for 192.168.20.0/24 via 10.0.0.3, more specific than the EIGRP summary.
  • show crypto ikev2 sa lists two peers: the hub and SPOKE2.

The first few packets go via the hub while the resolution and the IPsec negotiation finish. Expect one or two lost pings on the first attempt. That is normal, not a fault.

Tip

To see the redirect itself, run debug nhrp packet on the hub in a quiet lab and look for the traffic indication. Do not run it on a production hub. Use show ip nhrp traffic for counters instead.

NHRP shortcut entries expire. Stop traffic and watch show ip nhrp for the dynamic entries to disappear after the holdtime, then watch them return on new traffic. The default NHRP holdtime is 7200 seconds (check show ip nhrp for the live value on your image), so use clear ip nhrp to reset the lab instead of waiting.

Common failures

Symptom Likely cause Check
Spoke stays in IKE state in show dmvpn Underlay broken, PSK mismatch, or IKEv2 profile not matching the peer show crypto ikev2 sa, debug crypto ikev2
Spoke stays in NHRP state IPsec is fine but NHRP registration fails: wrong NHS address, NBMA address, or mismatched tunnel key show ip nhrp nhs detail, compare tunnel keys
IKE up, EIGRP neighbors do not form No multicast mapping on the hub or the spoke ip nhrp map multicast dynamic on hub, multicast keyword on the spoke NHS line
Spokes reach the hub but traffic between spokes always goes via the hub ip nhrp redirect missing on hub or ip nhrp shortcut missing on spoke, or spokes receive specific routes instead of the summary show run interface Tunnel0, show ip route on the spoke
Small pings work, large transfers stall MTU or MSS problem from GRE and ESP overhead ping ... size 1400 df-bit, ip tcp adjust-mss
First packets are lost, then all is fine Expected: resolution and IPsec negotiation None needed
Tunnel flaps after the hub reload Spoke NHS entry does not recover, or crypto session is stale clear crypto session, show ip nhrp nhs

A few of these deserve more detail.

Pre-shared key mismatch. The log shows an authentication failure from IKEv2. Check show crypto ikev2 sa detail and debug crypto ikev2. Remember that the local and remote keys in the keyring are used for the matching direction. In this lab both are identical, so the mismatch is almost always a typo on one router.

IKEv2 profile not selected. If the match identity remote address statement does not cover the peer, the responder cannot find a profile and the exchange fails. Test with 0.0.0.0 first, then narrow it.

Summary missing. If the hub does not summarize, spokes learn the specific LANs with the hub as next hop. Traffic still goes through the hub, but the spoke already holds a specific route, so the shortcut behaves differently from the design you intended. Verify that show ip route on the spoke shows only the summary.

Redirect works one way. SPOKE1 builds a shortcut but SPOKE2 does not. Check that SPOKE2 also has ip nhrp shortcut and that the underlay allows IKE (UDP 500, UDP 4500 for NAT-T) and ESP (IP protocol 50) in both directions. In a lab the ISP router has no ACLs, but on a real path a firewall in front of one spoke is a common cause.

Spoke behind NAT. NAT-T (UDP 4500) can carry the shortcut tunnel, but spoke-to-spoke between two spokes that are both behind NAT often fails or is unreliable. Test it before promising it.

Warning

Do not leave debug crypto ikev2 or debug nhrp packet running on a busy router. Use undebug all as soon as you have what you need.

Cleanup and extensions

When you finish, save the configs and keep them as a baseline. Good follow-ups:

  • Add a second hub and a second DMVPN cloud for redundancy. Add a second ip nhrp nhs line on each spoke.
  • Replace the pre-shared keys with certificates and compare the two setups.
  • Put the tunnels in a VRF (front-door VRF for the underlay) so the internet routes and the overlay routes are separate.
  • Replace EIGRP with BGP and compare convergence after you shut a spoke uplink.

If you are building the routing foundation, the CCNP study plan covers the underlying IGP and BGP topics.

References