DMVPN - Understanding Phase1, 2, & 3 with Boiler Templates

"The What?" - In this blog I want to cover configuring & verifying DMVPN. I will also provide boiler templates for hub/spokes configuration.

"The Why?" - DMVPN provides several benefits which include:

• Superior network speed and performance reliability

• Better connectivity between branches by integrating VPN into existing communication practices

• Conservation of WAN bandwidth

• Reduced bandwidth requirements at the hub

• Increased network resiliency and redundancy

• Secure routing with IPsec.

To see more about DMVPN see: DMVPN Tidbit

"The How?" - Before we dive in here are the DMVPN configuration blocks:

• mGRE

• NHRP

• Routing protocols

• IPsec

Technically speaking mGRE from a spoke perspective is not introduced until phase 2. So for the spokes in phase 1 the tunnels are statically configured with gre and a tunnel destination. Note to that ikev1 was used & then EIGRP for routing.

Phase1 Boiler Template Configs:

Hub:
interface Tunnel10
 ip address 200.200.200.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip split-horizon eigrp 1 --so routes are advrt. out same int
 ip nhrp authentication CIFELLI
 ip nhrp network-id 100
 ip nhrp map multicast dynamic 
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile Cifelli
!
crypto ipsec profile CIFELLI
 set transform-set trans 
!
crypto ipsec transform-set trans esp-aes 256 esp-sha512-hmac 
 mode tunnel
!
crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 19
!
crypto isakmp key CIFELLI address 0.0.0.0 

Spoke/s:
interface Tunnel10
 ip address 200.200.200.3 255.255.255.0
 ip mtu 1400
 ip nhrp authentication CIFELLI
 ip nhrp map 200.200.200.1 100.100.100.1 --create a static mapping for the hub’s tunnel address and the hub’s NBMA address
 ip nhrp map multicast 100.100.100.1 --where to forward multicast packets to
 ip nhrp network-id 10
 ip nhrp nhs 200.200.200.1 --specify next hop server (hub)
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1.100
 tunnel destination 100.100.100.1
 tunnel key 1
 tunnel protection ipsec profile CIFELLI
!
crypto ipsec profile CIFELLI
 set transform-set trans 
!
crypto ipsec transform-set trans esp-aes 256 esp-sha512-hmac 
 mode tunnel
!
crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 19
!
crypto isakmp key CIFELLI address 0.0.0.0 

FYSA, In the simple topology I have EIGRP enabled between the three devices. On the hub do not forget to disable split-horizon ;)

Verification from each spoke (csr2/csr3) that the paths flow through the hub:

DMVPN Phase 2:

With DMVPN phase 2 the major changes are introduced on the spokes. Instead of static gre tunnels to the hub we configure mgre on the spokes too. This enables dynamic spoke to spoke tunnels thanks to nhrp's crucial role. In this DMVPN with EIGRP scenario, you will want to enable this on the hub for phase2/3:

#no ip next-hop-self eigrp 1 --hub does not use self for rt updates

Note that not doing so will still have routes learned advertised with next hop being the hub.

Something else important to note for phase2 is that the initial nhrp resolution request is still sent from spoke1 to the hub, who then forwards it to the other spoke, which in turn responds and establishes the dynamic tunnel via nhrp resolution reply packet. Better than phase1, but there is still a better way.

Phase2 Boiler Template Configs (the only changes are on the tunnel interfaces on the spokes):

interface Tunnel10
 ip address 200.200.200.3 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication CIFELLI
 ip nhrp map 200.200.200.1 100.100.100.1
 ip nhrp map multicast 100.100.100.1
 ip nhrp network-id 10
 ip nhrp nhs 200.200.200.1
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint --mgre instead of static tunnel dest.
 tunnel key 1
 tunnel protection ipsec profile CIFELLI
end

Phase2 verification:

EIGRP route table is updated showing route to 3.3.3.3 from csr2 as direct:

Trace to other spoke goes directly to the spoke & does not traverse hub:

You can see the dynamic tunnel built to our other spoke:

Note that a simple ping & debug ip nhrp will show you nhrp in action covering registations, resolution request to hub, forwarded request to spoke, & finally the resolution reply to form the dynamic spoke to spoke tunnel.

DMVPN Phase 3: With phase 3 the major changes include configuration changes on both spokes & hub/s. NHRP indication messages are used to inform spokes of better paths. This is achieved via enabling nhrp redirect on hub & nhrp shortcut on spokes. The redirect command is essentially triggering the hub to tell the spoke there is a better path & here is the route, and the shortcut command triggers the spoke to accept this redirect route and install the shortcut.

Phase 3 Boiler Template Configs:

Hub:
interface Tunnel10
 ip address 200.200.200.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 CIFELLI
 ip nhrp network-id 100
 ip nhrp redirect --enabling redirects
 no ip split-horizon
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile Cifelli
Spoke:
interface Tunnel10
 ip address 200.200.200.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication CIFELLI
 ip nhrp map 200.200.200.1 100.100.100.1
 ip nhrp map multicast 100.100.100.1
 ip nhrp network-id 10
 ip nhrp nhs 200.200.200.1
 ip nhrp shortcut --enabling nhrp shortcut
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile Cifelli
end

Make sure you debug nhrp again to see the differences between phase2 & phase3. That about wraps this one up, Cheers!