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
Very useful lesson.
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.
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.
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.
The best way is to…test it 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.
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.
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
Yes you are right. Actually I don’t mean with this topic but wherever required like I checked your post Dual DMVPN.
Actually, I’m building a DMVPN lab 2 hubs and spokes. the 2 hubs is located in different subnets as follows :
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
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
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 18.104.22.168 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.
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.
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.
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 22.214.171.124/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!
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?
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!
Hi Laz, i odnt think that is the case.
SBYr01(config-if)#ip nhrp nhs 126.96.36.199 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 188.8.131.52 prio
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!