In the configuration of Hub2, the tunnel source interface is configured as GigabitEthernet 0/1. As you can see from the following diagram, you will see that the interface being used by the mGRE tunnel is indeed Gi0/1 and not Gi0/2:
Also, in the Spoke1 configuration, the ip nhrp map command must match the Hub2 Gi0/1 interface which is indeed 172.16.2.2. So the configurations look correct in the lesson. Can you clarify where you see the error?
After going through this lesson, as well as some of the DMVPN lessons involving OSPF routing, I suggest you attempt to create the topology yourself. It will be an excellent exercise to get you more familiar with the topology and the technologies used. As you go along, if you find youâre having difficulty, let us know and we can help you out.
Hello, I am afraid I am having the same confusion as agouassou1 above with regards to Hub 2.
I agree the diagram shows g0/1 however from the config this seems to be part of the Tunnel 1/ISP1 cloud (192.168.1.0/24), used as the source for Tunnel2. If Tunnel 2 source was re-configured to g0/2 (or the interface configs swapped) then it seems to be that would be the correct ISP (2) for tunnel 2 (192.168.2.0/24).
I noticed also that the second interface in the Hub configs has a config for the second cloud but do not appear to have an interface connection on the diagram.
In a dual hub, dual cloud set up, is it the case that the clouds should be effectively separate with no communication between them though DMVPN? So in the example, we wouldnât expect connectivity from Hub loopbacks (if configured) other than through the additional 10.10.10.0/24 network which interconnects them at R1?
You are indeed correct about the configurations, it seems that there is a slight confusion there. I will let Rene know to make any necessary corrections. As for the second link to the second cloud for each hub, that too looks strange. I will mention it to Rene as well to make any needed corrections.
Hi Rene,
Thanks for the topic. I followed exactly the configuration, successfully ping R1 . When I shut tunnel interface on hub1, traffic will choose the path through hub2, which is successfull. But then when I no shut tunnel interface on hub1 again, nhrp mapping has type incomplete, , flags : negative , routing on tunnel interface become flapping. I turn on debug on hub1, It said cannot mapping.
There are several issues that can arise when using DMVPN with two hubs. The issues have to do with the way NHRP reconverges after a failure and a recovery. This differs based on several parameters, including whether a dual cloud or single cloud is used.
Sometimes the failure recovers if enough time is given, sometimes up to three minutes. In your case, I suggest the following:
Try to give several minutes to your topology to recover. See if itâs simply a matter of timers.
Secondly, take a look at some of the following troubleshooting documentation and community threads that may help in your troubleshooting process:
Let us know how you get along and if you need any further assistance.
Thanks for your replying.
I created the topology to test. And I realized that I just turn off spokeâs tunnel interface and turn it on back will trigger a new NHRP Registration Request to hub, and everything is fine. One thing I noticed is that, when hub is on, show ip nhrp detail command wonât show mapping information. If we just trigger one spoke to register to the hub, only that spoke mapping information will be cache by hub. Even though the timers expired, hubâs cache only show 1 spoke that trigger NHRP Registration Request. So I decided to trigger the other spoke and it worked fine.
Thanks for sharing your experience with us, itâs always useful to have such information posted on the forum, as it helps others facing similar situations.
Hello everyone. I read the article and im still dont understand the use of tunnel key. Since the spoke routers have two different physical interfaces so the delivery header has different source ip why the hub cant know which tunnel to use? The hub is in different subnet and the spokes have one interface each in tha same subnet. Im a bit of confused
Strictly speaking, for the specific topology in question, you are correct. The tunnel key is unnecessary due to the unique IP addressing of tunnel interfaces, the fact that different interfaces are used at the spokes for connection to each hub, and because each hub has only a single tunnel. However, it is always best practice in such a case to use the tunnel key, because the topology does not always operate under ânormal operationâ. Even in a dual hub, dual cloud scenario, tunnel keys can still play an important role, depending on the network design and the requirements. Having the tunnel key will aid in the following areas:
Scalability - As your network grows, you may add more hubs and spokes, and this time add them by terminating the tunnels on the same interface, thus necessitating the use of the tunnel key.
Traffic engineering - The tunnel key can also be used as a parameter to route different types of traffic via different tunnels. You can also use the tunnel keys to enforce specific routing policies.
Troubleshooting, traffic monitoring, and ease of configuration - Having tunnel keys will help to monitor and troubleshoot traffic, and they can also be used as âlabelsâ to help you keep track of the tunnels that you create, especially in more complex scenarios.
It is best practice to use the tunnel keys simply because they will typically be needed as your network grows, and/or in situations where a particular part of the network may fail, and redundancy kicks in.
