DMVPN Dual Hub Single Cloud

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

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

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

please advise

Thanks

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

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.

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

Hi @lagapides 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#

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

thank you very much, Lazaros!

1 Like

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

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

1 Like

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.

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

1 Like

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 ?

Got it!

Thank you for the quick respone.

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