This topic is to discuss the following lesson:
https://networklessons.com/cisco/ccie-routing-switching/dmvpn-phase-2-eigrp-routing/
This topic is to discuss the following lesson:
https://networklessons.com/cisco/ccie-routing-switching/dmvpn-phase-2-eigrp-routing/
Rene,
What is the impact if the traffic go to the hub then to the other spoke ?
Ahmad,
The network will still function, but it will not be optimized. By having traffic go Spoke-Hub-Spoke instead of Spoke-Spoke, you could experience the following:
Great Answer . One thing I need to understand. With spoke to spoke traffic how would the physical path determined ? I believe if it wasn’t spoke to spoke ( spoke-hub-spoke) then the physical path must first hit the hub before reaching the other spoke. Can you clarify this ? Thank you.
Ahmad,
One of the key features (and limitations) of DMVPN Phase 2 is that each spoke can learn routes to every other spoke directly. It learns about these routes from the Hub, so it is ultimately up to the spoke to make its own determination via BGP or its own routing protocol, the best path to take to get to another spoke.
So think of it this way: In Phase 2, the Hub is still the “hub” for the control plane–all routes are learned through the hub. Spokes cannot exchange routes with each other directly. However, the Hub is no longer necessarily in the data plane–meaning spoke to spoke traffic can bypass the hub directly.
The limitation of this, by the way, (and why DMVPN Phase 2 is considered obsolete), is that in very large networks, it becomes a burden for every single spoke router to learn about all possible routes to every other spoke router (even if they are never needed). Phase 3 fixes this by allowing the use of summarization and default routes in combination with a “redirect” from the Hub. This allows spokes not become so burdened with unnecessary routes.
Wow. Clear. Thank you.
Hi Rene,
I am dealing with another issue using GNS3.
during the phase 2 configuration.
Symptoms:
1- the Hub is neighbor ONLY with spoke1
2- Spoke2 and Spoke3 are neighbor with the Hub however the adjacency is flapping
I did a debug on the hub and it never receive hello from spoke2 and spoke3 but I sending hello packets, debug on spoke2 show hello packets coming from the Hub and the spoke sending hello out.
Thanks again for your help.
have you experienced that type of issue ? do you have any recommendation ?
Hi Wandjlaye,
It’s been awhile since I used GNS3. I would recommend to test this on some newer IOS 15 routers first, just to make sure it’s not a GNS3 issue. Try it on Cisco VIRL or on some real routers.
Rene
Is it possible to configure Spoke1 and Spoke2 so they can ask Hub:
“Hi NHRP server, I need to send multicast so give me public addresses for all routers”?’
If it is not possible - are there any important consequence that Spokes cannot exchange multicast?
Hello Lukasz
Concerning your first question, it is possible to use the dynamic
command at each spoke in such a network topology, however, it is best practice to have each spoke configured with a static NHRP mapping, since there is only one mapping, and that is to the interface of the Hub router. This removes unnecessary traffic on the tunnels that would be used for each spoke to learn the mapping dynamically using NHRP. With two spokes, this may not seem very traffic intensive, but if you have tens of spokes, you can immediately see how traffic and the necessary resources required for dynamic mapping can increase.
The Hub on the other hand can also be configured statically but it is best practice to use the dynamic
command as this prevents the necessity of a separate configuration line for a multicast mapping for each spoke router.
Concerning your question about the ip next-hop-self eigrp
command, this is the default setting for all interfaces. In other words, any and all advertisements that are sent from interface X will have a next hop address equal to that of the X interface. So the answer is c).
The no ip next-hop-self eigrp
command is implemented on a per interface basis, either a tunnel interface or otherwise. This command will make an interface send out an advertisement and will KEEP the original next hop address, that is, the next hop address that it learned when it received the information itself.
So in this specific topology:
* Spoke 1 informs the Hub via EIGRP of a route to 2.2.2.2 via the next hop address of 172.16.123.2
* The Hub then advertises this information to Spoke 2 via the Tunnel 0 interface, using EIGRP and tells Spoke 2 that a route to 2.2.2.2 exists with a next hop IP of 172.16.123.2 (as opposed to 172.16.123.1)
I hope this has been helpful!
Laz
What network equipment did you use for the “internet”?
Was it a router or a L2 switch?
Hi Corwyn,
I used a L2 switch. If you use DMVPN over the Internet, you can’t use a default route like I did on the tunnel interfaces since you already use a default route towards the ISP. You can use summary routes to overcome this or VRFs.
Rene
Hi, I am facing the same issue. Any solution?
Hello Nagachn
There’s no documented solution this issue, however, I was able to find some information about flapping EIGRP adjacencies over DMVPN topologies. Take a look at this Cisco Community thread that deals with some of these issues.
I hope this has been helpful!
Laz
Thanks for the help. Let met try again.
We have to use the exclusive " ip nhrp map multicast in the spoke routers to make EIGRP work. In the latest IOS Versions, the “ip nhrp map multicast dynamic” is default ( HUB Router).
Hello Nagarajan
Thanks for pointing this out. It is indeed confirmed that the ip nhrp map multicast
command is necessary to allow IGP routing protocols to function in the DMVPN environment. It is also confirmed that the ip nhrp map multicast dynamic
command is by default enabled on Cisco IOS XE Denali 16.3 and later. The following two documents contain this information:
Thanks for pointing that out!
Laz