To continue with DMVPN topic, this post will be explaining DMVPN Phase-2. The main difference between Phase-1 and 2 is the spoke to spoke reachability. As shown in the previous post, a spoke can only reach another spoke through the Hub. There is no direct spoke to spoke communication. Phase-2, however, changes this behavior where spokes can talk to each other directly.

I’m going to use the same topology and IP addressing. So let’s go directly to the actual configuration.

DMVPN Phase-2: Static Mapping

R1:
interface Tunnel0
 ip address 10.1.1.1 255.255.255.0
 ip nhrp map 10.1.1.2 192.168.1.2
 ip nhrp map 10.1.1.3 192.168.1.3
 ip nhrp map 10.1.1.4 192.168.1.4
 ip nhrp network-id 111
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

R2:
interface Tunnel0
 ip address 10.1.1.2 255.255.255.0
 no ip redirects
 ip nhrp map 10.1.1.1 192.168.1.1
 ip nhrp map 10.1.1.3 192.168.1.3
 ip nhrp map 10.1.1.4 192.168.1.4
 ip nhrp network-id 111
 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 10.1.1.2 192.168.1.2
 ip nhrp map 10.1.1.4 192.168.1.4
 ip nhrp network-id 3
 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 10.1.1.2 192.168.1.2
 ip nhrp map 10.1.1.3 192.168.1.3
 ip nhrp network-id 444
 tunnel source 192.168.1.4
 tunnel mode gre multipoint

As you might have noticed, R1 has the exact same config as Phase-1, so no changes there. The main difference is in the spoke sites. First, there is no “tunnel destination <ip_address>” command, it is replaced with “tunnel mode gre multipoint” – which makes sense since we don’t only want a tunnel between the hub and spoke, but we need to bring up tunnels between the spokes themselves. On the same note here, you notice that we needed to complete the mapping between all other routers since having his mapping on the hub only will not work. We need direct mapping in each spoke so we can enable spoke to spoke communication, bypassing the hub. Let’s review some outputs here:

As the traceroute commands show, we are no longer going through the hub for spoke to spoke communication. Now, let’s enable EIGRP on all routers:

router eigrp 100
 network 10.1.1.0 0.0.0.255

Additionally, as in the previous post, we will have to enable multicast on the hub:

R1:
interface Tunnel0
 ip nhrp map multicast 192.168.1.2
 ip nhrp map multicast 192.168.1.3
 ip nhrp map multicast 192.168.1.4

As in the previous post, we will need to disable EIGRP split-horizon on R1’s tunnel interface.

At this point, you should see all three spokes formed EIGRP neighbor relationship with the hub. Let’s confirm:

If you noticed the above behavior, when we traceroute to R3/10.1.1.3 we go directly to there bypassing the hub as expected. However, this is not the case when we traceroute to R3/30.30.30.30 – what is exactly happening here?

This behavior is due to the fact that EIGRP by default update the next hop. So as 30.30.30.30 is being advertised to R1 (next hop is 10.1.1.3), when R2 advertises it back to the other spokes, it put itself as the next hop (10.1.1.1) as shown in the above screenshot.

We can fix this either by configuring “ip nhrp multicast” commands on the spokes so they form EIGRP relationship with each other which will take care of the next hop. Alternatively, and a better solution, is to disable the next hop self using the command ” no ip next-hop-self eigrp 100” under R’1s tunnel interface.

DMVPN Phase-2: Dynamic Mapping

As in the previous post, we are going to replace the static mapping with dynamic:

R1: 
interface Tunnel0
 no ip nhrp map 10.1.1.2 192.168.1.2
 no ip nhrp map 10.1.1.3 192.168.1.3
 no ip nhrp map 10.1.1.4 192.168.1.4
 ip nhrp map multicast dynamic

Same needs to be done on spoke sites R3 for example:

R3:
interface Tunnel0
 no ip nhrp map 10.1.1.2 192.168.1.2
 no ip nhrp map 10.1.1.4 192.168.1.4
 ip nhrp map multicast 192.168.1.1
 ip nhrp nhs 10.1.1.1

A couple of important things to note here. Note that we did not remove ” ip nhrp map 10.1.1.1 192.168.1.1” as this is still needed to tell the spoke how to reach to the hub to register with the command ” ip nhrp nhs 10.1.1.1” Also note that we had to enable multicast with the hub to enable EIGRP hello’s. Let’s test the connectivity:

The screenshot above shows a very interesting thing which is the very nature of the DMVPN. Notice that R3 does not have a Dynamic tunnel with R2.

Below, I started to ping R2 which initiates the tunnel between R3 and R2

Also note that we are still bypassing the hub when we 2 spokes communicate with each other (I still have split-horizon and next-hop-self disabled on R1’s tunnel interface.

In the next and last post, I will go over DMVPN Phase-3