Welcome back to this series, where we have been looking at DMVPN redundancy. In the past articles, we have considered dual ISP links on a single hub router and we have also seen dual hub routers with separate ISP links.

CCNA Training – Resources (Intense)

In this article, we will move over to redundancy at the remote site, i.e., at the spokes. We will be using the diagram below:

As you can see in the diagram above, the hub has a single ISP link while the spokes have dual ISP links. Keep in mind that the “Internet” cloud does not have to be the “Internet” – it could be a private WAN cloud between the hub and the spokes or a mixture of the two.

This scenario is quite similar to the one where we had a single hub with dual ISP links. In that scenario, we configured two options:

  1. Two DMVPN clouds with IP SLA tracking to determine when to failover between ISP links. You can find that here.
  2. Two DMVPN clouds and VRF-Lite where one ISP link was in the global VRF and the other was in its own VRF. You can find that here.

In this article, we will configure something similar to the second option. except that the ISP links will be configured in two different VRFs (not the global VRF). An example of where this kind of configuration is useful is when we want all traffic from the spokes (including Internet traffic) to flow through the hub. Since we will be using dynamic routing in the DMVPN clouds, the hub router will advertise a default route to the spokes via the DMVPN tunnel. The problem with this, however, is that the spoke routers will already (probably) have a default route to their ISP and this default route will be used to form the DMVPN tunnel with the hub.

Now, if the hub also advertises a default route through the tunnel, this advertised default route will not be used because of the already existing default route to the ISP. Assuming the default route advertised by the hub over the tunnel has a better administrative distance (or metric) than the one configured to the ISP, then the spoke router will try to use the better default route (the one from the hub), which will break the DMVPN tunnel since the DMVPN tunnel is formed through the default route to the ISP.

By using the VRF-Lite feature, we can have different default routes in the VRFs and another default route (advertised by the hub) in the global VRF.

Note: You may have to read the last three paragraphs again to understand the problem I have described.

Let’s begin with the configuration on the hub. We will configure two DMVPN clouds and since we will be using the same tunnel source, we will have to add the shared keyword to the tunnel protection profile command. Also, we will make one tunnel preferred over the other by adjusting the delay values. Finally, we will configure DMVPN Phase 3 using ip nhrp redirect on the hub and ip nhrp shortcut on the spokes:

hostname HUB
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0      
!         
crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac 
 mode tunnel
!
crypto ipsec profile IPSEC_PROF
 set transform-set TRANS_SET 
!
interface Tunnel1
 description ***PRIMARY DMVPN CLOUD***
 ip address 10.1.123.1 255.255.255.0
 no ip redirects
 no ip split-horizon eigrp 10
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 ip summary-address eigrp 10 0.0.0.0 0.0.0.0
 delay 1000
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile IPSEC_PROF shared
!
interface Tunnel2
 description ***BACKUP DMVPN CLOUD***
 ip address 10.2.123.1 255.255.255.0
 no ip redirects
 no ip split-horizon eigrp 10
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 2
 ip nhrp redirect
 ip summary-address eigrp 10 0.0.0.0 0.0.0.0
 delay 1500
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 2
 tunnel protection ipsec profile IPSEC_PROF shared
!
interface Ethernet0/0
 description ***ISP LINK***
 ip address 41.1.10.2 255.255.255.252
!
interface Loopback10
 description ***LAN***
 ip address 10.10.10.1 255.255.255.0
!
router eigrp 10
 network 10.1.123.0 0.0.0.255
 network 10.2.123.0 0.0.0.255
 network 10.10.10.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 41.1.10.1

Let’s now move to the spoke routers. We will create two VRFs—ISP1-VRF and ISP2-VRF—and assign the respective ISP links to these VRFs. We will also use the tunnel vrf command under the tunnel interfaces so that post-GRE encapsulated packets are forwarded correctly.

The configuration on SPOKE1 is as follows:

ip vrf ISP1-VRF
 description ***VRF FOR ISP1***
 rd 1:1
!
ip vrf ISP2-VRF
 description ***VRF FOR ISP2***
 rd 1:2
!
interface Ethernet0/0
 description ***PRIMARY ISP LINK***
 ip vrf forwarding ISP1-VRF
 ip address 41.1.20.2 255.255.255.252
!
interface Ethernet0/1
 description ***BACKUP ISP LINK***
 ip vrf forwarding ISP2-VRF
 ip address 192.0.20.2 255.255.255.252
!
interface Loopback20
 description ***LAN***
 ip address 10.10.20.2 255.255.255.0
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
! Enable DPD
crypto isakmp keepalive 10 periodic
!
! PSK for ISP1-VRF
crypto keyring ISP1_PSK vrf ISP1-VRF
  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
!
! PSK for ISP2-VRF
crypto keyring ISP2_PSK vrf ISP2-VRF
  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
!
crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac 
 mode tunnel
!
crypto ipsec profile IPSEC_PROF
 set transform-set TRANS_SET 
!
interface Tunnel1
 description ***PRIMARY DMVPN CLOUD***
 ip address 10.1.123.2 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp map multicast 41.1.10.2
 ip nhrp map 10.1.123.1 41.1.10.2
 ip nhrp network-id 1
 ip nhrp nhs 10.1.123.1 
 ip nhrp shortcut
 delay 1000
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel vrf ISP1-VRF
 tunnel protection ipsec profile IPSEC_PROF
!
interface Tunnel2
 description ***BACKUP DMVPN CLOUD***
 ip address 10.2.123.2 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp nhs 10.2.123.1 nbma 41.1.10.2 multicast
 ip nhrp network-id 2
 tunnel source Ethernet0/1
 tunnel mode gre multipoint
 tunnel key 2
 tunnel vrf ISP2-VRF
 tunnel protection ipsec profile IPSEC_PROF
!
router eigrp 10
 network 10.1.123.0 0.0.0.255
 network 10.2.123.0 0.0.0.255
 network 10.10.20.0 0.0.0.255
!
! Default routes to ISPs on each VRF
ip route vrf ISP1-VRF 0.0.0.0 0.0.0.0 41.1.20.1
ip route vrf ISP2-VRF 0.0.0.0 0.0.0.0 192.0.20.1
!

Hint: Notice the command ip nhrp nhs 10.2.123.1 nbma 41.1.10.2 multicast under Tunnel2. This one command replaces the following three commands: ip nhrp map multicast 41.1.10.2, ip nhrp map 10.2.123.1 41.1.10.2 and ip nhrp nhs 10.2.123.1. This command was introduced in IOS 15.1(2)T.

Note: The configuration on SPOKE2 is similar to the one on SPOKE1, so it is not shown here for the sake of brevity.

To verify our configuration, we can check the crypto sessions on one of the spokes to see that both tunnels are up:

However, because of the adjusted delay values on the tunnel interfaces, Tunnel1 will be preferred to forward traffic:

Notice that the only EIGRP route on the spoke is the default EIGRP route advertised by the Hub because of the EIGRP summary address we configured on the hub tunnel interfaces.

Let’s try to ping between the LAN interface of the spoke and that of the hub:

We can also confirm that spoke-to-spoke tunnels will be built. To test this, we will first perform a traceroute from SPOKE1’s LAN to SPOKE2’s LAN, and see that it goes through the hub:

However, because of NHRP redirect and shortcut, the hub informs the spoke that it can reach that destination directly. Therefore, the spokes will build a dynamic tunnel between themselves and, when we perform a traceroute again, the hub is bypassed:

The output of the crypto session will also show us that this dynamic tunnel was indeed built:

To finalize this article, we can test if failover works by shutting down the primary ISP link. If everything is configured correctly, the default route from Tunnel2 should now be installed in the routing table:

Summary

This brings us to the end of this article, where we have considered redundancy at the spoke sites, i.e., the spoke routers had dual ISP links. We used front-door VRF in our configuration, similar to what we did in the scenario where a single hub had dual ISP links.

Based on the scenarios we have considered so far, you should have enough information to configure other variations, such as where the hub and the spoke routers have dual ISP links.

To wrap up the series, we will look at one last scenario where we will use fully qualified domain names (FQDNs) in our DMVPN configuration.

References and Further Reading