This is the third and final post regarding DMVPN which will cover Phase-3. Phase-2 and Phase-3 are very similar. In both phases, spokes can access each other directly by bringing an on demand tunnel. That said, there is some minor configuration difference and specific commands that we need to add to the tunnel interfaces of the hub and spokes. I feel like I have covered a good amount of static mapping in the previous two posts, I will just use dynamic mapping here.

R1:
interface Tunnel0
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 111
 ip nhrp redirect
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

R2:
interface Tunnel0
 ip address 10.1.1.2 255.255.255.0
 no ip split-horizon eigrp 100
 ip nhrp map 10.1.1.1 192.168.1.1
 ip nhrp map multicast 192.168.1.1
 ip nhrp network-id 111
 ip nhrp nhs 10.1.1.1
 ip nhrp shortcut
 tunnel source 192.168.1.2
 tunnel mode gre multipoint

R3:
interface Tunnel0
 ip address 10.1.1.3 255.255.255.0
 no ip redirects
 ip nhrp map 10.1.1.1 192.168.1.1
 ip nhrp map multicast 192.168.1.1
 ip nhrp network-id 3
 ip nhrp nhs 10.1.1.1
 ip nhrp shortcut
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

R4:
interface Tunnel0
 ip address 10.1.1.4 255.255.255.0
 no ip redirects
 ip nhrp map 10.1.1.1 192.168.1.1
 ip nhrp map multicast 192.168.1.1
 ip nhrp network-id 444
 ip nhrp nhs 10.1.1.1
 ip nhrp shortcut
 tunnel source 192.168.1.4
 tunnel mode gre multipoint

The main difference between Phase-2 and Phase-3 are the above commands in red. Basically, when a spoke does not know where to send the traffic to bring the tunnel with another spoke, it sends that registration to the hub which is configured to ‘redirect’ that registration to the right spoke. The spoke that initiated the the registration is configured with ‘shortcut’ command, so it will make a note of how to reach the spoke directly next time it needs to, bypassing the hub.

Let’s review the output:

In the first screenshot, notice that the hub have tunnels up with all spokes. Also notice that EIGRP neighbors are all up. Double check R1 tunnel interface config, we have not disabled EIGRP next hop – unlike Phase-2 where we needed to to do that.

In the second screenshot, notice that initially, R4 only had a static tunnel to the hub (by configuration). Once I pinged R2, R4 brought up a tunnel with R2 dynamically.

Same thing with the third screenshot, check how first trace from R4 to R3 had to go through the hub (because R4 did not have a direct tunnel with R3) – but the second trace went directly to R3.