DMVPN Dual Hub Dual Cloud

In previous DMVPN lessons I explained how to configure a small DMVPN network using a hub and two spoke routers. The disadvantage of a single hub router is that it’s a single point of failure. Once your hub router fails, the entire DMVPN network is gone.

To add redundancy to our DMVPN network we need to add another hub router. There are two options for this:

Dual hub – Single Cloud
Dual hub – Dual Cloud

With the single cloud option we use a single DMVPN network but we add a second hub. The spoke routers will use only one multipoint GRE interface where we configure the second hub as a next hop server.

The dual cloud option also has two hubs but we will use two DMVPN networks which means that all spoke routers will get a second multipoint GRE interface.

In this lesson we’ll take a look at the dual hub dual cloud option. This is the best option for DMVPN dual hub. Take a look at the following picture:

DMVPN Dual Hub Dual Cloud Overview

Above we have two hub routers and two spoke routers. Each hub router will be connected to a different ISP and we will create two DMVPN networks. The spoke routers will be connected to both DMVPN networks which means they’ll have two multipoint GRE interfaces. The main advantage of using two interfaces is that it’s easy to influence your routing. The only disadvantage is that it takes a bit more time to build this configuration.

Configuration

To demonstrate all of this, we’ll use the following topology:

DMVPN Dual Hub Dual Cloud Topology

Above we have the R1 router which is on the main site. Hub1 and hub2 provide access to our main network and are connected to different ISPs. This is not a requirement but for redundancy, it makes sense to use a different ISP for each hub.

The spoke routers are connected to both ISPs and will connect to both DMVPN networks. R1, spoke1 and spoke2 each have a loopback interface which we will advertise in a routing protocol.

Hub routers

Let’s start with the hub routers:

Hub1(config)#interface Tunnel1
Hub1(config-if)#ip address 172.16.1.1 255.255.255.0
Hub1(config-if)#ip nhrp authentication DMVPN
Hub1(config-if)#ip nhrp map multicast dynamic
Hub1(config-if)#ip nhrp network-id 1
Hub1(config-if)#tunnel source GigabitEthernet0/1
Hub1(config-if)#tunnel mode gre multipoint
Hub1(config-if)#tunnel key 1
Hub2(config)#interface Tunnel2
Hub2(config-if)#ip address 172.16.2.2 255.255.255.0
Hub2(config-if)#ip nhrp authentication DMVPN
Hub2(config-if)#ip nhrp map multicast dynamic
Hub2(config-if)#ip nhrp network-id 2
Hub2(config-if)#tunnel source GigabitEthernet0/1
Hub2(config-if)#tunnel mode gre multipoint
Hub2(config-if)#tunnel key 2

The configuration of the hub routers is identical except:

  • We use a different NHRP network ID.
  • We use a different tunnel key.
  • We use a different subnet for each tunnel.
Without the tunnel key, the router won’t know which interface to use to de-encapsulate packets. For a detailed explanation, take a look at the GRE tunnel key lesson.

Spoke routers

Let’s configure the spoke routers:

Spoke1(config)#interface Tunnel1
Spoke1(config-if)#ip address 172.16.1.3 255.255.255.0
Spoke1(config-if)#ip nhrp authentication DMVPN
Spoke1(config-if)#ip nhrp map 172.16.1.1 192.168.1.1
Spoke1(config-if)#ip nhrp map multicast 192.168.1.1
Spoke1(config-if)#ip nhrp network-id 1
Spoke1(config-if)#ip nhrp nhs 172.16.1.1
Spoke1(config-if)#tunnel source GigabitEthernet0/1
Spoke1(config-if)#tunnel mode gre multipoint
Spoke1(config-if)#tunnel key 1
Spoke1(config)#interface Tunnel2
Spoke1(config-if)#ip address 172.16.2.3 255.255.255.0
Spoke1(config-if)#ip nhrp authentication DMVPN
Spoke1(config-if)#ip nhrp map 172.16.2.2 192.168.2.2
Spoke1(config-if)#ip nhrp map multicast 192.168.2.2
Spoke1(config-if)#ip nhrp network-id 2
Spoke1(config-if)#ip nhrp nhs 172.16.2.2
Spoke1(config-if)#tunnel source GigabitEthernet0/2
Spoke1(config-if)#tunnel mode gre multipoint
Spoke1(config-if)#tunnel key 2

The spoke routers will have two tunnel interfaces. The configuration is pretty much the same but make sure you use the correct tunnel address, NBMA address, NHRP network ID and tunnel key.

We can copy the configuration of spoke1 to spoke2, the only difference is the IP address:

Spoke2(config)#interface Tunnel1
Spoke2(config-if)#ip address 172.16.1.4 255.255.255.0
Spoke2(config-if)#ip nhrp authentication DMVPN
Spoke2(config-if)#ip nhrp map 172.16.1.1 192.168.1.1
Spoke2(config-if)#ip nhrp map multicast 192.168.1.1
Spoke2(config-if)#ip nhrp network-id 1
Spoke2(config-if)#ip nhrp nhs 172.16.1.1
Spoke2(config-if)#tunnel source GigabitEthernet0/1
Spoke2(config-if)#tunnel mode gre multipoint
Spoke2(config-if)#tunnel key 1
Spoke2(config)#interface Tunnel2
Spoke2(config-if)#ip address 172.16.2.4 255.255.255.0
Spoke2(config-if)#ip nhrp authentication DMVPN
Spoke2(config-if)#ip nhrp map 172.16.2.2 192.168.2.2
Spoke2(config-if)#ip nhrp map multicast 192.168.2.2
Spoke2(config-if)#ip nhrp network-id 2
Spoke2(config-if)#ip nhrp nhs 172.16.2.2
Spoke2(config-if)#tunnel source GigabitEthernet0/2
Spoke2(config-if)#tunnel mode gre multipoint
Spoke2(config-if)#tunnel key 2

This takes care of the DMVPN networks. Let’s verify our work:

Hub1#show dmvpn | begin Peers
Type:Hub, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.1.3          172.16.1.3    UP 00:18:06     D
     1 192.168.1.4          172.16.1.4    UP 00:05:55     D
Hub2#show dmvpn | begin Peers
Type:Hub, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.2.3          172.16.2.3    UP 00:00:45     D
     1 192.168.2.4          172.16.2.4    UP 00:01:40     D

Each hub router has two registration, one for each spoke router. We can now focus on the routing configuration.

EIGRP

This time I’ll use EIGRP as the routing protocol. We will advertise all loopback and tunnel interfaces in EIGRP:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 740 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

551 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Awesome, thanks Rene,

    what does the tunnel-key do? i just spent ages trying to get this topology working but forgot the tunnel key command, i was using OSPF and only 1 neighbour fully established, the other just stuck at INIT

  2. The tunnel key is necessary so the router can figure out which tunnel interface is responsible for processing the incoming encapsulated packet. You can’t rely on the destination address because it becomes a chicken-and-egg problem: Which tunnel interface should be used to de-encapulate the packet, so the destination address can be read to determine which tunnel interface should be used? :slight_smile:

    The tunnel-key solves this problem.

  3. Hi Team,

    I just had an interesting experience configuring my second hub, I forgot too add the no split horizon eigrp # command. I was getting the following errors:

    Mar  1 01:23:08.639: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.254.0/24 - do advertise out Tunnel2
    *Mar  1 01:23:08.639: IP-EIGRP(Default-IP-Routing-Table:1): Int 192.168.254.0/24 metric 128256 - 256 128000
    *Mar  1 01:23:08.723: IP-EIGRP(Default-IP-Routing-Table:1): Processing incoming UPDATE packet
    *Mar  1 01:23:08.723: IP-EIGRP(Default-IP-Routing-Table:1): Int 192.168.254.0/24 M 429
    ... Continue reading in our forum

  4. Hi Fabian,

    Split horizon (on or off) won’t prevent your router from becoming neighbors with another router. It will only prevent it from advertising.

    The metric (4294967295) that you see in your debug is the highest value and is considered an infinite distance.

    Rene

  5. Hi Rene,

    a question regarding OSPF with dual cloud DMVPN… i am currently labbing this for deploymant at one of my customers and i cannot find the answer as how to achieve the EIGRP stub functionality in OSPF, as my spoke router has dual connections its becoming a transit router when a certain downstream link fails (which i dont want) is there a way in OSPF to only advertise connected routes?

17 more replies! Ask a question or join the discussion by visiting our Community Forum