Welcome back to this series on DMVPN Redundancy. In the first two articles, we looked at a design where a single DMVPN hub had two ISP links and we used two different methods to configure that scenario.

CCNA Training – Resources (Intense)

In this article, we will move on to another scenario where we have dual DMVPN hubs connected to different ISPs. For this scenario, we will be using the following diagram:

There are two ways we can go about configuring this design:

  1. We can have a single DMVPN cloud with both hubs in the same cloud. This means that spoke routers will have only one tunnel interface.
  2. We can have dual DMVPN clouds with each hub controlling its own cloud. This means that spoke routers will have two tunnel interfaces – one for each DMVPN cloud.

For this article, we will look at the
first option and then consider the second option in the next article. We will begin by configuring the routers and then discussing the issues that surround this design and how they can be overcome.

We will be considering a primary/backup scenario where HUB1 will be the primary hub and HUB2 the backup hub. The configuration on HUB1 is as follows:

hostname HUB1
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10 periodic
!
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 ***DMVPN CLOUD***
 ip address 172.16.0.1 255.255.255.0
 no ip redirects
 no ip next-hop-self eigrp 10
 no ip split-horizon eigrp 10
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 delay 1000
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile IPSEC_PROF
!
interface Ethernet0/0
 description ***LINK TO ISP1***
 ip address 192.0.2.2 255.255.255.252
!
interface Ethernet0/1
 description ***LAN***
 ip address 10.10.10.1 255.255.255.0
!
router eigrp 10
 network 172.16.0.0 0.0.0.255
 network 10.10.10.0 0.0.0.255
!
ip route 0.0.0.0 0.0.0.0 192.0.2.1

As you can see, there’s nothing different on this hub router than on any normal DMVPN configuration. Let’s move on to the configuration on HUB2 (the secondary hub):

hostname HUB2
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10 periodic
!
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 ***DMVPN CLOUD***
 ip address 172.16.0.2 255.255.255.0
 no ip redirects
 no ip next-hop-self eigrp 10
 no ip split-horizon eigrp 10
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 delay 2000
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile IPSEC_PROF
!
interface Ethernet0/0
 description ***LINK TO ISP1***
 ip address 41.1.1.2 255.255.255.252
!
interface Ethernet0/1
 description ***LAN***
 ip address 10.10.10.2 255.255.255.0
!
router eigrp 10
 network 172.16.0.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.1.1

For now, I will leave the configuration on this second hub router the way it is. However, there is still something that we need to do especially if OSPF is used as the routing protocol and we will discuss this later.

The configuration on SPOKE1 is as follows:

hostname SPOKE1
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
crypto isakmp key cisco address 0.0.0.0
crypto isakmp keepalive 10 periodic
!
crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac
 mode tunnel
!
crypto ipsec profile IPSEC_PROF
 set transform-set TRANS_SET
!
interface Loopback0
 description ***LAN interface***
 ip address 10.10.20.2 255.255.255.0
!
interface Tunnel1
 description ***DMVPN CLOUD***
 ip address 172.16.0.10 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp map multicast 192.0.2.2
 ip nhrp map 172.16.0.1 192.0.2.2
 ip nhrp map multicast 41.1.1.2
 ip nhrp map 172.16.0.2 41.1.1.2
 ip nhrp nhs 172.16.0.1
 ip nhrp nhs 172.16.0.2
 ip nhrp network-id 1
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile IPSEC_PROF
!
interface Ethernet0/0
 description ***INTERNET LINK***
 ip address 192.0.2.6 255.255.255.252
!
router eigrp 10
 network 172.16.0.0 0.0.0.255
 network 10.10.20.0 0.0.0.255
!
! Default route to ISP
ip route 0.0.0.0 0.0.0.0 192.0.2.5

The difference between the configuration on this spoke router and any normal DMVPN spoke router has to do with the configuration on the tunnel interface. Like we already said, since we are using a single DMVPN cloud, there will only be one tunnel. However, since there are two hubs, we had to configure multiple NHRP-related commands for both hubs: NHRP multicast mappings, static NHRP mappings and NHS definitions.

Note: The configuration on SPOKE2 is similar to the one on SPOKE1 except for IP addressing; therefore it is not shown here. SPOKE2 will have an IP address of 172.16.0.11 in the DMVPN cloud.

Let’s look at some verification commands. We can begin by viewing the EIGRP neighbors on HUB1:

As you can see, HUB1 has 4 EIGRP neighbors: 2 over the tunnel interface – SPOKE1 and SPOKE2 – and 2 over its LAN interface – HUB2 and another router on the LAN. One thing you will notice is that the hub routers are not EIGRP neighbors over their tunnel interfaces. This can especially be problematic with OSPF because you want one hub to be the DR and the other to be the BDR.

To resolve this issue, we will configure one hub (the secondary hub i.e. HUB2) as a client of the primary hub as follows:

interface Tunnel1
 ip nhrp map multicast 192.0.2.2
 ip nhrp map 172.16.0.1 192.0.2.2
 ip nhrp nhs 172.16.0.1

With this configuration, HUB1 and HUB2 are now EIGRP neighbors:

Now let’s consider routing. Because we have adjusted the delay values on the tunnel interfaces of the hub routers, devices on the LAN behind these routers will prefer HUB1 to forward traffic to the spoke networks. For example, this is the routing table of a router behind the hub routers for the spoke networks:

However, looking at the EIGRP topology on this internal router reveals a problem:

From the output above, notice that HUB2 is not listed as a feasible successor for any of the EIGRP routes.

We can look at the routing table of HUB2 to identify the problem:

The problem is that HUB2 is also using HUB1 to reach the spoke networks even though it has other feasible successors for those networks in its EIGRP topology table:

The ideal situation is that HUB2 should use its own tunnel interface to reach those spoke networks. However, because the metric through the LAN interface is better, HUB2 is using HUB1. To solve this problem, you will need to understand how EIGRP calculates its metrics and work out how to alter it.

In this case, the desired solution will be achieved by setting the delay on the Tunnel1 interface of HUB2 to anything between 1001 and 1099.

Note: It may not be the same for your network because the EIGRP metric is based on both bandwidth and delay.

I have used a delay value of 1099 and the result on HUB2 is as follows:

With this configuration change, the internal router will now have HUB2 as a feasible successor even though HUB1 will still be used as the primary path:

Let’s now move on to routing at the spoke sites.

As you can see, the spokes will use both hubs to reach the network behind the hub, which may result in asymmetric routing – LAN devices behind the hubs use HUB1 to forward traffic to the spoke but the spoke can use both links. Since there’s only one tunnel interface through which the EIGRP adjacencies with both hubs are formed, adjusting anything on this tunnel interface will affect both hubs and is therefore not a solution.

However, there are several ways to overcome this issue. For example, on the hub that should be used as a backup, we can increase the metric of the LAN network as advertised to spokes using an offset list. The following configuration on HUB2 will achieve this:

ip access-list standard INCR_METRIC
 permit 10.10.10.0 0.0.0.255
!
router eigrp 10
 offset-list INCR_METRIC out 25600 Tunnel1

With this configuration, SPOKE1 now uses HUB1 as the primary path but will use HUB2 in case of any failure of the primary hub:

Another method you could use on the spoke is to increase the Administrative Distance (AD) for routes advertised by HUB2:

ip access-list standard INCR_METRIC
 permit 10.10.10.0 0.0.0.255
!
router eigrp 10
 distance 91 172.16.0.2 0.0.0.0 INCR_METRIC

Note: It is generally not recommended to alter AD because it may result in routing loops.

To conclude this article, let’s test that failover works. I will run a ping from SPOKE1, shut down HUB1’s ISP’s interface and then bring it back up.

The first highlighted section shows the loss when the ISP interface of HUB1 was shutdown – notice that the EIGRP neighbor adjacency went down. After the failure, the spoke began using HUB2. The second highlighted section shows the loss when the ISP interface was brought back up and the spoke was preparing to go back to using HUB1 as the preferred path.

One of the advantages of this design is that since the spokes use only one tunnel, then you don’t run into the issue discussed in the first article: performance issues on certain devices that don’t support hardware acceleration for tunnels configured with the tunnel key command.

One disadvantage is that it can be quite challenging to achieve load balancing (use both hubs simultaneously), avoid asymmetric routing and also ensure failover. The second design option can better overcome this disadvantage as we will see in the next article.

Summary

In this article, we have considered another DMVPN design scenario where there are dual hubs connected to different ISPs and we configured them to operate in the same DMVPN cloud. We saw some issues with this design and discussed ways to resolve them.

In the next article, we will configure the
second option we mentioned in this article – dual DMVPN clouds. I hope you have found this article insightful.

References and Further reading