DMVPN Dual Hub Single 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:

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 single cloud option. Take a look at the following picture:

DMVPN Dual Hub Single Cloud Overview

Above you can see a DMVPN network with two hubs and two spoke routers. Hub1 will be the primary hub, hub2 is the secondary hub. We use a single DMVPN network, each router only has one multipoint GRE interface.

The advantage of this setup is that it’s very easy to implement. The configuration of hub2 is similar to hub1. On the spoke routers we only have to add the second router as a hub.

The disadvantage is that we have limited control when it comes to routing. Since we use a single multipoint GRE interface, it’s difficult to make the spoke routers prefer one hub over another.

Let’s take a look at the configuration and you’ll see the advantages and disadvantages in action…

Configurations

Here’s the topology we will use:

DMVPN Dual Hub Single Cloud Topology

Above we have five routers. On top we have R1 which is located on the main site where we use the 10.10.10.0/24 subnet. Behind R1 we have a loopback interface with IP address 1.1.1.1/32.

The two hub routers and spoke routers are connected to the Internet. Normally you would connect the two hub routers to different ISPs and we would use public IP addresses. To keep it simple, I connected all routers to the 192.168.1.0/24 subnet.

Each spoke router has a loopback interface with an IP address.

The DMVPN network will use subnet 172.16.1.0/24 where hub1 will be the primary hub. Spoke routers will register themselves with both hub routers.

Hub Routers

Let’s start with the hub1 router:

Hub1(config)#interface Tunnel 0
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 GigabitEthernet 0/1
Hub1(config-if)#tunnel mode gre multipoint

The configuration above is a basic DMVPN hub configuration that I have used in all my examples so far. Let’s configure the hub2 router:

Hub2(config)#interface Tunnel 0
Hub2(config-if)#ip address 172.16.1.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 1
Hub2(config-if)#tunnel source GigabitEthernet 0/1
Hub2(config-if)#tunnel mode gre multipoint

The configuration above is exactly the same as the hub1 router (except for the IP address). However there is one more thing left to do on the hub2 router:

Hub2(config)#interface Tunnel 0
Hub2(config-if)#ip nhrp map 172.16.1.1 192.168.1.1
Hub2(config-if)#ip nhrp map multicast 192.168.1.1
Hub2(config-if)#ip nhrp nhs 172.16.1.1

The hub2 router is a hub but will also be a client of the hub1 router. This is required when we want to configure a routing protocol like OSPF. The hub1 router will be the DR of our DMVPN network and it will require a neighbor adjacency with all routers, including the hub2 router. Hold this thought for now, we’ll configure OSPF in a bit…

Spoke routers

Let’s start with the spoke1 router:

Spoke1(config)#interface Tunnel 0
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 172.16.1.2 192.168.1.2
Spoke1(config-if)#ip nhrp map multicast 192.168.1.1
Spoke1(config-if)#ip nhrp map multicast 192.168.1.2
Spoke1(config-if)#ip nhrp network-id 1
Spoke1(config-if)#ip nhrp nhs 172.16.1.1
Spoke1(config-if)#ip nhrp nhs 172.16.1.2
Spoke1(config-if)#tunnel source GigabitEthernet 0/1
Spoke1(config-if)#tunnel mode gre multipoint

The configuration above is a basic DMVPN spoke configuration. The only difference is that we included the following additional three commands for the hub2 router:

  • ip nhrp map 172.16.1.2 192.168.1.2
  • ip nhrp map multicast 192.168.1.2
  • ip nhrp nhs 172.16.1.2

By adding these three commands, our spoke routers can use a second hub router. This makes it very easy to add redundancy to our DMVPN network.

Let’s do the same thing on the spoke2 router:

Spoke2(config)#interface Tunnel0
Spoke2(config-if)#ip address 172.16.1.4 255.255.255.0
Spoke2(config-if)#no ip redirects
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 172.16.1.2 192.168.1.2
Spoke2(config-if)#ip nhrp map multicast 192.168.1.1
Spoke2(config-if)#ip nhrp map multicast 192.168.1.2
Spoke2(config-if)#ip nhrp network-id 1
Spoke2(config-if)#ip nhrp nhs 172.16.1.1
Spoke2(config-if)#ip nhrp nhs 172.16.1.2
Spoke2(config-if)#tunnel source GigabitEthernet0/1
Spoke2(config-if)#tunnel mode gre multipoint

Let’s see if our configuration is correct:

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

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.1.2          172.16.1.2    UP 00:00:31     D
     1 192.168.2.3          172.16.1.3    UP 00:00:34     D
     1 192.168.2.4          172.16.1.4    UP 00:00:29     D
Hub2#show dmvpn | begin Peers
Type:Hub/Spoke, NHRP Peers:3, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.1.1          172.16.1.1    UP 00:00:45     S
     1 192.168.2.3          172.16.1.3    UP 00:00:41     D
     1 192.168.2.4          172.16.1.4    UP 00:00:43     D

Above you can see that the hub1 router has three dynamic NHRP registrations, the two spoke routers and hub2.

The hub2 router has two dynamic registrations, one for each spoke router.

We can also verify this from the spoke routers:

Spoke1#show dmvpn | begin Peers
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.1.1          172.16.1.1    UP 00:01:41     S
     1 192.168.1.2          172.16.1.2    UP 00:01:35     S
Spoke2#show dmvpn | begin Peers
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.1.1          172.16.1.1    UP 00:01:43     S
     1 192.168.1.2          172.16.1.2    UP 00:01:43     S

Our DMVPN network is up and running. Let’s configure a routing protocol…I’ll pick OSPF since it’s a good example to demonstrate the disadvantage of the single cloud option.

OSPF

We will use two areas for this network. Between R1, hub1 and hub2 we will use area 0. The DMVPN network will use area 1. Let’s start with the backbone area:

R1(config)#router ospf 1
R1(config-router)#network 10.10.10.0 0.0.0.255 area 0
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
Hub1(config)#router ospf 1
Hub1(config-router)#network 10.10.10.0 0.0.0.255 area 0
Hub2(config)#router ospf 1
Hub2(config-router)#network 10.10.10.0 0.0.0.255 area 0

Now we can configure the DMVPN network. Make sure the hub1 router becomes the DR and hub2 the BDR. The spoke routers should never be elected as DR/BDR:

Hub1(config)#interface Tunnel 0
Hub1(config-if)#ip ospf network broadcast
Hub1(config-if)#ip ospf priority 2

Hub1(config)#router ospf 1
Hub1(config-router)#network 172.16.1.0 0.0.0.255 area 1
Hub2(config)#interface Tunnel 0
Hub2(config-if)#ip ospf network broadcast
Hub2(config-if)#ip ospf priority 1

Hub2(config)#router ospf 1
Hub2(config-router)#network 172.16.1.0 0.0.0.255 area 1
Spoke1(config)#interface Tunnel 0
Spoke1(config-if)#ip ospf priority 0
Spoke1(config-if)#ip ospf network broadcast 

Spoke1(config)#router ospf 1
Spoke1(config-router)#network 172.16.1.0 0.0.0.255 area 1
Spoke1(config-router)#network 3.3.3.3 0.0.0.0 area 1
Spoke1(config)#interface Tunnel 0
Spoke2(config-if)#ip ospf priority 0
Spoke2(config-if)#ip ospf network broadcast 

Spoke2(config)#router ospf 1
Spoke2(config-router)#network 172.16.1.0 0.0.0.255 area 1
Spoke2(config-router)#network 3.3.3.3 0.0.0.0 area 1

That takes care of the OSPF configuration. Let’s verify our work:

Spoke1#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.1       2   FULL/DR         00:00:38    172.16.1.1      Tunnel0
192.168.1.2       1   FULL/BDR        00:00:33    172.16.1.2      Tunnel0
Spoke2#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.1       2   FULL/DR         00:00:39    172.16.1.1      Tunnel0
192.168.1.2       1   FULL/BDR        00:00:36    172.16.1.2      Tunnel0

Above we can see that the spoke routers see hub1 as the DR and hub2 as the BDR. Let’s take a look at the routes that we learned:

R1#show ip route ospf

      3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/1002] via 10.10.10.254, 00:03:44, GigabitEthernet0/1
                 [110/1002] via 10.10.10.253, 00:01:44, GigabitEthernet0/1
      4.0.0.0/32 is subnetted, 1 subnets
O IA     4.4.4.4 [110/1002] via 10.10.10.254, 00:03:44, GigabitEthernet0/1
                 [110/1002] via 10.10.10.253, 00:01:44, GigabitEthernet0/1
      172.16.0.0/24 is subnetted, 1 subnets
O IA     172.16.1.0 [110/1001] via 10.10.10.254, 00:03:44, GigabitEthernet0/1
                    [110/1001] via 10.10.10.253, 00:01:44, GigabitEthernet0/1

R1 is seeing two equal cost paths. What about the hub routers?

Hub1#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 10.10.10.1, 00:04:26, GigabitEthernet0/2
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.1.3, 00:04:26, Tunnel0
      4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/1001] via 172.16.1.4, 00:04:26, Tunnel0
Hub2#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 10.10.10.1, 00:04:45, GigabitEthernet0/2
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.1.3, 00:02:36, Tunnel0
      4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/1001] via 172.16.1.4, 00:02:36, Tunnel0

The hub routers will use their own tunnel interfaces to reach the spoke routers.

Let’s check spoke1 and spoke2:

Spoke1#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/1002] via 172.16.1.2, 00:01:50, Tunnel0
                 [110/1002] via 172.16.1.1, 00:05:01, Tunnel0
      4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/1001] via 172.16.1.4, 00:04:51, Tunnel0
O IA  10.10.10.0/24 [110/1001] via 172.16.1.2, 00:01:50, Tunnel0
                     [110/1001] via 172.16.1.1, 00:05:01, Tunnel0
Spoke2#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/1002] via 172.16.1.2, 00:02:06, Tunnel0
                 [110/1002] via 172.16.1.1, 00:05:17, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.1.3, 00:05:07, Tunnel0
O IA  10.10.10.0/24 [110/1001] via 172.16.1.2, 00:02:06, Tunnel0
                     [110/1001] via 172.16.1.1, 00:05:17, Tunnel0

The spoke routers have two equal cost paths through the hub1 and hub2 routers.

What if we want to use hub1 as the primary router and hub2 only as a backup? Perhaps hub1 is connected to a fast dedicated internet connection and hub2 is using a slow backup DSL connection.

This can be a challenge…traffic from R1 towards the spoke routers is no problem but the other way around will be. Let me show you:

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 654 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

535 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. Hi This is an excellent article.

    But I have one quesion.

    HUBs
    ip nhrp network-id 1
    
    SPOkES
    ip nhrp network-id 2
    

    Is it Ok that HUBs and SPOKEs network-id is different?

  2. Hi Rene,
    Actually, I’m building a DMVPN lab 2 hubs and spokes. the 2 hubs is located in different subnets as follows :
    Hub01 :

    
    interface Tunnel0
     ip address 172.16.253.1 255.255.255.0
     no ip redirects
     ip nhrp authentication DMVPN
     ip nhrp map multicast dynamic
     ip nhrp network-id 1
     tunnel source GigabitEthernet0
     tunnel mode gre multipoint
     !
    end
    
    

    Hub02 :

    
    interface Tunnel0
     ip address 172.16.254.1 255.255.255.0
     no ip redirects
     ip nhrp authentication DMVPN
     ip nhrp map multicast dynamic
     ip nhrp network-id 2
     tunnel source GigabitEthernet0
     tunnel mode gr
    ... Continue reading in our forum

  3. Hi Soufiane,

    EIGRP will produce this error when you have two devices on the same segment, sending hello packets to each other but using different subnets. Any chance your spoke routers are connecting to the wrong hub / using the wrong tunnel? Without EIGRP, are you able to ping the tunnel interfaces?

    You might want to compare my configs with yours, you should be able to load mine (with EIGRP) and run those without any errors.

    Rene

  4. Hello Dawit

    By using the show dmvpn command on the spoke routers, you can see that there are indeed two peers. Both hub routers are registered. You can also check routing in the spokes and see that there are indeed two equal cost routes via both hubs. You can even shut down the interface of Hub1 and check both the DMVPN peering as well as the routing and verify that hub 2 is indeed showing up in both routes and peers.

    Note here that both hubs appear as equals, that is, that both are used simultaneously, as they are considered equal cost paths. If you want t

    ... Continue reading in our forum

  5. Hello Laz,
    Show DMVPN command output shows in spoke router :
    hub1 is up and hub2 is NHRP state.

    please advise

    Thanks

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