DMVPN Phase 2 EIGRP Routing

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Rene,

What is the impact if the traffic go to the hub then to the other spoke ?

3

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:

  1. Bandwidth Saturation: With a large number of spokes, the Hub’s bandwidth could become saturated with all the traffic that could be going between the spokes directly
  2. Increased delay: Applications that are sensitive to delay (like voice or video) might experience adverse effects because of the extra hops and introduced delay with Spoke-Hub-Spoke traffic
  3. Increased dependence on the Hub being available: Even through the Hub will remain a single point of failure for the control plane (meaning the spokes still depend on the hub to learn about spoke to spoke routes), once a spoke establishes spoke to spoke communication, the hub could go down for a short time and not interrupt the traffic between spokes (that have already learned of each other). With Spoke-Hub-Spoke data flow, this means that the Hub is also in the data plane of the traffic, so if the hub has any interruption in service, even for a moment, then spoke to spoke traffic will suffer.
2 Likes
4

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.

5

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.

1 Like
6

Wow. Clear. Thank you.

7

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 ?

8

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

9
  1. Why don’t You configure Spoke1 and Spoke2 simalar to Hub the with the command:
    **ip nhrp map multicast dynamic**

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?

  1. How does the command “ip next-hop-self eigrp” exactly work? Does it work:
    a) only for routes learnt AND sent via tunnel interface?
    b) for routes learnt via tunnel interface AND sent via ANY interface?
    c) for each route sent via tunnel interface
10

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

11

What network equipment did you use for the “internet”?
Was it a router or a L2 switch?

12

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

13

Hi, I am facing the same issue. Any solution?

14

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.


See if implementing some of the stated solutions resolves your issue. As Rene mentioned in his previous post, it may also be a GNS3 issue that may have to do with the IOS verion used, so you may want to experiment with other emulators, or with real devices. Let us know how you get along with any of these possible solutions, and if you need additional help, you know where to find us.

I hope this has been helpful!

Laz

15

Thanks for the help. Let met try again.

1 Like
16

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).

17

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

1 Like
18

Hi

What is actually preventing spokes from forming neighbor adjacencies between eachother ? They are both running EIGRP on the same subnet and have the same AS number

19

Hello Hammad

This is an excellent question, and it is actually answered within the Introduction to DMVPN lesson. Specifically, it states for DMVPN Phase 2:

We are using a hub and spoke topology so only the hub will exchange routing information with the spokes. Depending on the routing protocol, it’s possible that the hub changes the next hop IP address of routes that it advertises to the spokes. When it does then a spoke will use the hub as the destination when it’s trying to reach a remote spoke. I’ll show you how to deal with this when we look at the configuration.

So you see, even though the spokes are on the same subnet, and in an Ethernet environment, this would allow those routers to become EIGRP neighbors, the fact that a spoke will always try to reach another spoke via the hub disallows the automatic creation of EIGRP neighbors from spoke to spoke.

I hope this has been helpful!

Laz

20

Thanks for your help, but if you can help me more with this question: is the problem of spokes cant form neighbor adj is because they configured to send multicast to NHS only?