DMVPN Dual Hub Single Cloud

This topic is to discuss the following lesson:

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?

All interfaces that belong to the same DMVPN network should use the same network ID. I just fixed it, that was a copy/paste error :slight_smile:

Very useful lesson.

Thanks Rene.

I think below can be control the route also

For OSPF, if the Hub network is redistributed will be easy as Hub 1 can advertised as E1 and Hub 2 advertised as E2.

For EIGRP, Hub2 also can use AD or Metric to manipulate the route for Spoke.

Davis

Hi Davis,

You could use redistribution to influence how the spoke routers reach R1 on top. Hub1 could advertise regular OSPF routes and hub2 could redistribute these routes.

Getting from the hubs to the spoke routers is harded though, the spoke routes are advertising the same info to both hub routers.

EIGRP is a bit more flexible than OSPF.

Rene

Thanks Rene.

Davis

Rene,

Hello! How do we do fail over test if we have HQ1 is primary site and another site is Backup site of HQ2. IPsec GRE tunnel primary with (HQ1) and secondary with (HQ2) how can I do fail over test to verify if HQ site goes down at Primary site , secondary will come up?

These two sites are connected via internet services.

Thank you
Shraddha

Hi Shraddha,

The best way is to…test it :slight_smile: If you have configured everything correctly, try it during a maintenance window. Or if you are not sure, configure this in VIRL / GNS3 to see if failover works correctly.

Rene

Hi Rene,

I liked this article.

Almost all your example includes 2-3 device.

can u please add 4-5 device in all lab configuration to make it little hard.

Thank You
Sanjiv

Hi Sanjiv,

I usually use the minimum number of devices that is required to demonstrate something. Like in this example, it wouldn’t matter if you have 2 or 20 spoke routers. It’s just a matter of copy/pasting the spoke configuration for each additional device :slight_smile:

Rene

Hi Rene,

Yes you are right. Actually I don’t mean with this topic but wherever required like I checked your post Dual DMVPN.

Thanks
Sanjiv

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 gre multipoint
end

Spoke :


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

interface Tunnel1
 ip address 172.16.254.2 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map multicast 192.168.0.3
 ip nhrp map 172.16.254.1 192.168.0.3
 ip nhrp network-id 2
 ip nhrp nhs 172.16.254.1
 tunnel source GigabitEthernet0
 tunnel mode gre multipoint
 !
end
'

The problem is when I add the network to the eigrp I have this error :

router eigrp 100
 network 3.3.3.3 0.0.0.0
 network 172.16.253.0 0.0.0.255
 network 172.16.254.0 0.0.0.255

Oct 5 16:49:45.184: EIGRP-IPv4(100): Neighbor 172.16.253.1 not on common subnet for Tunnel1

Thank you for the advice.

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

Hi Rene!
Is it always important to give the HUB-2 information about HUB-1 via:

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

And if yes, why not HUB-1 giving information about HUB-2 also the same way (as I saw in a Cisco community entry but without explaination)

Or does it only apply for OSPF?
I want to use EIGRP over the DMVPN cloud.

Best regards
Alex

Hello Alex,

Good question.

With OSPF, we configure hub2 as a client of hub1 since the DR (hub1) requires a neighbor adjacency with all routers, including hub2.

EIGRP doesn’t have this requirement. Technically, the spokes only have to form a neighbor adjacency with hub1 and hub2. There is no need to form a neighbor adjacency between hub1 and hub2.

However, hub2 will receive EIGRP packets on its tunnel interface from hub1. Without the nhrp commands you mention, hub2 will have no idea how to reach 172.16.1.1 (hub1). It can’t map 172.16.1.1 to anything. You’ll see a flapping EIGRP neighbor adjacency on hub2.

To fix this, I guess you could configure static neighbors (not ideal) or perhaps filter incoming hub1 EIGRP traffic on hub2. Turning hub2 into a client of hub2 is probably the easiest solution. One disadvantage of doing this is that when hub2’s Gi0/3 fails, it will use hub1 over DMVPN to reach the 10.10.10.0/24 and 1.1.1.1/32 network. Unless that’s something you want. I can’t think of a reason why hub1 should also become a client of hub2.

If you want to implement this, I would go for the dual DMVPN dual hub solution btw.

Hope this helps!

Rene

I see where your lesson says there is no way in a single cloud to make one server be used over redundant servers.

I see in the config on the spoke one has the priority option when one is statically configuring the NHRP server, can you comment?

Hello Mark

I am assuming you mean the DMVPN Dual Hub Single Cloud lesson, and that you are referring to Rene’s comment that

“Since we use a single multipoint GRE interface, it’s difficult to make the spoke routers prefer one hub over another.”

The priority command implemented is for the configuration of OSPF, and specifically, for the OSPF DR and BDR elections, and not for the NHRP operation.

I hope this has been helpful!

Laz

Hi Laz, i odnt think that is the case.

SBYr01(config-if)#ip nhrp nhs 1.1.1.1 

  cluster   NHS cluster, don't specify for default cluster
  nbma      NBMA of NHS
  priority  NHS priority, don't specify for default priority
  <cr>

SBYr01(config-if)#ip nhrp nhs 1.1.1.1 prio

Hello Mark

Ah, I see. I thought you were speaking about the priority command in OSPF. So, in this lesson, Rene mentions that it is difficult to use hub1 as the primary route and hub2 as the secondary route. The reason for this is that we are using a single multipoint GRE interface. Even if you use the priority option for NHRP, that just makes the hub be a primary or secondary next hop resolution server. The routing is still limited to what OSPF can do. As Rene states, the single multipoint GRE interface limits the operation of OSPF because:

  • OSPF supports “per neighbor cost” but this doesn’t work for our broadcast network type.
  • On older IOS versions you could change the administrative distance per OSPF neighbor, this doesn’t work anymore. (the AD will be changed for all neighbors if you try this).
  • We can use a distribute-list to prevent the spoke routers from installing routes from the hub2 router.
  • We can use summarization on the hub2 router so that the spoke1 routers prefer the more specific prefixes from the hub1 router.

If we want to be able to have both hubs as options for routing traffic, the best would be to implement a dual hub dual cloud configuration as shown in the following lesson:

As Rene states in the lesson:

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.

I hope this has been helpful!

Laz

Hello Rene,
How do I know or check that the spoke(s) will pickup Hub2 if Hub 1 is down?

Thanks