DMVPN Dual Hub Single Cloud

lagapidis · June 10, 2019, 4:37am

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 to choose one over the other, as the lesson states, it can be a bit more challenging.

I hope this has been helpful!

Laz

dbeshir · June 10, 2019, 6:02am

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

please advise

Thanks

lagapidis · June 10, 2019, 8:05am

Hello Dawit

In the lesson, you can see that the states shown of the DMVPN peers in the spokes are UP for both hubs. Now if in your topology you have a state of NHRP, then you should also look at the state attributes at the end. If they are not S for static, then your tunnels may be incomplete. Take a look at the attributes and compare them to the legend in the output of the command to find out why.

I hope this has been helpful!

Laz

raj7988 · November 13, 2019, 5:59am

we can also configure the lowest cost on interface(Hub1) on which our R1 is connected, instead of configuring distribute list on spokes or configuring the summerization on HUB2.
Please let me know if i’m wrong.

lagapidis · November 13, 2019, 7:44am

Hello Raj

As you saw in the lesson, the tunnel interfaces cost was increased for Hub 2 and the result was that R1 had Hub 1 as the next hop for both spoke destinations. In the same way, by increasing the cost of the Gi0/3 interface on either Hub router will change the way that R1 routes traffic to the spokes.

However, this will not change the cost of the paths through hub 1 and hub 2 as seen from the point of view of the spokes. This is confirmed in the lesson as well. So return traffic would still be confined to Hub 1.

Unfortunately, only distribute lists or summarization can be used to achieve the desired result.

I hope this has been helpful!

Laz

yuriviniciusff · May 22, 2020, 7:32am

Hi @lagapidis I hope you are well!
I did a laboratory on this topic.
I first applied the summarization technique to make hub-1 primary / hub-2 backup. it worked !!!

in another moment I applied the technique of changing the cost of the interfaces in hub-2 to become backup and it also came out as expected.
I saw that you commented that this implementation would not work.

I’ll show you my config, see if I’m forgetting any details .

here is the topology used!

here is the configuration of costs changed in hub-2

HUB-2#sh run int tu0
interface Tunnel0
 ip address 192.168.1.4 255.255.255.0
 no ip redirects
 ip nhrp authentication yuri123
 ip nhrp map multicast dynamic
 ip nhrp map multicast 3.3.3.2
 ip nhrp map 192.168.1.1 3.3.3.2
 ip nhrp network-id 1
 ip nhrp nhs 192.168.1.1
 ip nhrp cache non-authoritative
 ip nhrp redirect
 ip ospf network broadcast
 **ip ospf cost 12000**
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 123
end

HUB-2#
HUB-2#
HUB-2#
HUB-2#sh run int fa0/1
Building configuration...

Current configuration : 113 bytes
!
interface FastEthernet0/1
 ip address 10.0.2.4 255.255.255.0
 **ip ospf cost 12000**
 duplex auto
 speed auto
end

HUB-2#

here are some commands on host-7 behind the HUB’s
the host apprehends the spoke prefix (10.0.0.0 ) by hub-1 (10.0.2.1) and the database contains the route that hub-2 is also sending, but does not enter the routing table.
the trace shows the path going through hub-1

R7-Host#sh ip route         
Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 3 subnets
C       10.0.2.0 is directly connected, FastEthernet0/0
**O IA    10.0.0.0 [110/11131] via 10.0.2.1, 00:06:38, FastEthernet0/0**
**O IA    10.0.1.0 [110/11131] via 10.0.2.1, 00:06:38, FastEthernet0/0**
O IA 192.168.1.0/24 [110/11121] via 10.0.2.1, 00:06:38, FastEthernet0/0
R7-Host#
R7-Host#
R7-Host#
R7-Host#
R7-Host#
R7-Host#
R7-Host#sh ip ospf database 

            OSPF Router with ID (10.0.2.7) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.0.2.7        10.0.2.7        420         0x80000003 0x00667B 1
192.168.1.1     192.168.1.1     420         0x80000003 0x00A68F 1
192.168.1.4     192.168.1.4     419         0x80000002 0x00CE5A 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.2.1        192.168.1.1     421         0x80000001 0x00A32D

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
**10.0.0.0        192.168.1.1     406         0x80000001 0x00E04A**
**10.0.0.0        192.168.1.4     406         0x80000001 0x00A803**
10.0.1.0        192.168.1.1     406         0x80000001 0x00D554
10.0.1.0        192.168.1.4     406         0x80000001 0x009D0D
192.168.1.0     192.168.1.1     455         0x80000001 0x004292
192.168.1.0     192.168.1.4     456         0x80000001 0x000A4B
R7-Host#
R7-Host#
R7-Host#
R7-Host#traceroute 10.0.0.1 

Type escape sequence to abort.
Tracing the route to 10.0.0.1

  **1 10.0.2.1 112 msec 40 msec 40 msec**
**  2 192.168.1.2 92 msec 120 msec 48 msec**

here shows the vision of spoke R1 for the return traffic to host-7 (10.0.2.0), going through hub-1

R1#sh ip route 
Gateway of last resort is 1.1.1.1 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
**O IA    10.0.2.0 [110/11121] via 192.168.1.1, 00:00:18, Tunnel0**
C       10.0.0.0 is directly connected, FastEthernet0/1
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 1.1.1.1
R1#

here I applied the shutdown to the tu0 interface of hub-1 to switch the traffic to hub-2

HUB-1#sh run int tu0
!
interface Tunnel0
 ip address 192.168.1.1 255.255.255.0
 no ip redirects
 ip nhrp authentication yuri123
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp cache non-authoritative
 ip nhrp redirect
 ip ospf network broadcast
 ip ospf priority 2
 **shutdown**
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 123
end

HUB-1#

after shutdown at hub-1 the view of host-7 behind the hub seizing the spoke route with a new cost and a new jump to hub-2

R7-Host#sh ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 3 subnets
C       10.0.2.0 is directly connected, FastEthernet0/0
**O IA    10.0.0.0 [110/12020] via 10.0.2.4, 00:01:20, FastEthernet0/0**
**O IA    10.0.1.0 [110/12020] via 10.0.2.4, 00:01:20, FastEthernet0/0**
O IA 192.168.1.0/24 [110/12010] via 10.0.2.4, 00:01:20, FastEthernet0/0
R7-Host#
R7-Host#
R7-Host#
R7-Host#
R7-Host#tra
R7-Host#traceroute 10.0.0.1

Type escape sequence to abort.
Tracing the route to 10.0.0.1

  **1 10.0.2.4 80 msec 48 msec 20 msec**
**  2 192.168.1.2 60 msec 92 msec 80 msec**
R7-Host#

and now the vision of spoke R1 after receiving update from hub-2

R1#sh ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 1.1.1.1 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 3 subnets
**O IA    10.0.2.0 [110/23111] via 192.168.1.4, 00:01:27, Tunnel0**
C       10.0.0.0 is directly connected, FastEthernet0/1
O       10.0.1.0 [110/11121] via 192.168.1.3, 00:01:27, Tunnel0
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 1.1.1.1
R1#

lagapidis · May 26, 2020, 5:47am

Hello Yuri

This looked very interesting, so I labbed it up again, and I found the following. It is not actually the change in the OSPF cost of the tunnel that makes the difference here. In my lab topology, I tried changing only the cost of the tunnel, but I was unable to replicate your results. I still got two equal-cost paths to the host behind the hubs. However, the difference is that you have also changed the OSPF cost of the FastEthernet0/1 interface, and it is this change that makes the difference.

The reason is that any change in the OSPF cost of the mGRE tunnel 0 on one hub will make a change to all routes on that multipoint tunnel, including those that go to the other hub. This is the point the lesson is making, and I made before, when stating that changing the OSPF cost doesn’t make a difference.

But here you have also changed the cost of the physical interface in the path, something that can be distinguished between the two hubs. The result is that only one route is then found within the routing tables of the spokes.

This was a great exercise, and thanks for putting in the time to examine this! It’s always useful to dig deeper.

I hope this has been helpful!

Laz

yuriviniciusff · May 26, 2020, 6:55am

thank you very much, Lazaros!

rangaraj.siqsess · August 8, 2020, 3:05pm

Hi Rene,

In the output below, NBMA addr of Spoke routers looks wrong. Hope they are typos?

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

Thanks,
Rangaraj

lagapidis · August 11, 2020, 8:06am

Hello Rangaraj

I was just composing an explanation, and I finally realized where the error is. Yes, you are correct, the Peer MBMA addresses should be:

192.168.1.2
192.168.1.3
192.168.1.4

The third octet should be 1 and not 2. The same goes for the output on Hub2 in the lesson. I will let Rene know to make the change.

Thanks for pointing that out!

Laz

chrisnewnham17 · August 25, 2020, 2:54pm

Interesting that you mention the AD can no longer be changed per neighbour. Do you have any more details around this as the command still seems to exist? Remember it’s the neighbour ID not IP, and affects the router that generated the route within the area, not necessarily the router you learned the route from.

lagapidis · August 27, 2020, 6:53am

Hello Chris

I went in and labbed this up to play around with the various options and what I found is that the distance command can be used to modify the administrative distance for routes that come from particular sources. You can also add an access list that will be applied to incoming routing updates.

As you mention the command exists. I tried changing the AD of the routes that come from the neighbor HUB2 to an AD of 115 using the following command on Spoke1 (note my IP addresses are a little different from those of the lesson, but the result is the same):

Spoke1(config-router)#distance 115 192.168.2.2 0.0.0.0
Spoke1(config-router)#do show ip route ospf | begin Gateway

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [115/1002] via 172.16.1.2, 00:00:05, Tunnel0
                 [115/1002] via 172.16.1.1, 00:00:05, Tunnel0
      4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/1001] via 172.16.1.4, 00:00:05, Tunnel0
O IA  192.168.1.0/24 [115/1001] via 172.16.1.2, 00:00:05, Tunnel0
                     [115/1001] via 172.16.1.1, 00:00:05, Tunnel0
Spoke1(config-router)#

You’ll notice that even though I specified the IP address of the particular neighbor (router ID of Hub2), all neighbor ADs changed to 115. The distance command also has the option of referencing an access list that is applied to incoming routing updates. Those updates reference particular prefixes rather than neighbor IDs. In this case, this doesn’t help us because we’re looking at the same prefix, so no differentiation in AD can be made there.

So it turns out that adjusting AD will indeed not work, as mentioned in the lesson. You can find out more about the distance command for OSFP at the following Cisco command reference:

Although I found that it was not very detailed, and didn’t include the nuances of the command, and that is why I did my experimentation above.

I hope this has been helpful!

Laz

dorsinai1004 · January 10, 2021, 7:43pm

Hey Rene,

It is the second time that I follow your scripts, but still failed to achive full connectivty from spokes to hubs (both 1,2).
I built a reflective lab of your demonstration during the lesson.

i keep getting on both spokes the following error:

*Jan 10 19:41:31.255: NHRP: Setting retrans delay to 64 for nhs  dst 192.16.1.1
*Jan 10 19:41:31.259: NHRP-ATTR:  Requester Ext Len: Total ext_len  with NHRP attribute VPE 49

*Jan 10 19:41:31.259: NHRP: Incompatible Destination NBMA (UNKNOWN) for 'Tunnel0'
Spoke2#
*Jan 10 19:41:59.167: NHRP: Setting retrans delay to 64 for nhs  dst 192.16.1.2
*Jan 10 19:41:59.167: NHRP-ATTR:  Requester Ext Len: Total ext_len  with NHRP attribute VPE 49
*Jan 10 19:41:59.167: NHRP: Incompatible Destination NBMA (UNKNOWN) for 'Tunnel0'

spoke 1:

interface Tunnel0
 ip address 172.16.1.3 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map 172.16.1.1 192.168.1.1
 ip nhrp map 172.16.1.2 192.168.1.2
 ip nhrp map multicast 192.168.1.1
 ip nhrp map multicast 192.168.1.2
 ip nhrp network-id 1
 ip nhrp nhs 192.16.1.1
 ip nhrp nhs 192.16.1.2
 tunnel source GigabitEthernet1/0
 tunnel mode gre multipoint

spoke 2:

 ip address 172.16.1.4 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map 172.16.1.1 192.168.1.1
 ip nhrp map 172.16.1.2 192.168.1.2
 ip nhrp map multicast 192.168.1.1
 ip nhrp map multicast 192.168.1.2
 ip nhrp network-id 1
 ip nhrp nhs 192.16.1.1
 ip nhrp nhs 192.16.1.2
 tunnel source GigabitEthernet1/0
 tunnel mode gre multipoint

I am using the 7200 appliiance.
Any advice ?

dorsinai1004 · January 12, 2021, 6:29am

Got it!

Thank you for the quick respone.

lagapidis · January 13, 2021, 7:08am

Hello Dor

It seems that for both spoke 1 and spoke 2, you have the following:

ip nhrp nhs 192.16.1.1
ip nhrp nhs 192.16.1.2

where it should be

ip nhrp nhs 172.16.1.1
ip nhrp nhs 172.16.1.2

The IP addresses used in this command should be those of the tunnel interfaces of the hubs.

Try that out and let us know your results.

I hope this has been helpful!

Laz

dorsinai1004 · January 13, 2021, 5:55pm

Thanks, i will change it.

tungpm92 · April 15, 2021, 7:04am

Hello Rene,
It is possible if we use DMVPN phase 3 Dual hub and OSPF for routing ?
I tried, but my lab is not working, when DR (hub1) off, BDR (hub2) is DR, but when Hub1 recoveried, the DMVPN is not working .

lagapidis · April 17, 2021, 8:49am

Hello Tung

In this lesson, Rene is configuring dual hub DMVPN using phase 2. It is possible to configure DMVPN dual hub in phase 3, by simply changing the configuration as you probably already did, to match the phase 3 configuration in this lesson.

There is an inherent problem with using OSPF on a dual hub single cloud phase 3 configuration. Actually, the problem is also there for phase 2 as well… Specifically, if Hub 1 which is the DR fails, hub 2 will become the DR. When Hub 1 returns, it will not assume the DR role until Hub 2 fails. So the fact that Hub 2 remains the DR becomes a problem. For this reason, it is preferable to deploy a dual hub dual cloud solution like the one in the link below if you are going to use OSPF. Otherwise, it is suggested that you use EIGRP.

I hope this has been helpful!

Laz

tungpm92 · April 21, 2021, 1:36pm

Thank you so much Lagapides !

Rahul_K · August 6, 2021, 5:59am

There are typos in section 1.3 for OSPF Configuration on Spoke 2.

Hostname

Spoke1(config)#interface Tunnel 0
Spoke2(config-if)#ip ospf priority 0
Spoke2(config-if)#ip ospf network broadcast

Wrong network statement. It should be 4.4.4.4 0.0.0.0 area 1

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