DMVPN Phase 2 EIGRP Routing

Wow. Clear. Thank you.

Hi Rene,

I am dealing with another issue using GNS3.
during the phase 2 configuration.

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.


  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

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 via the next hop address of
* The Hub then advertises this information to Spoke 2 via the Tunnel 0 interface, using EIGRP and tells Spoke 2 that a route to exists with a next hop IP of (as opposed to

I hope this has been helpful!


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.


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.

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!


Thanks for the help. Let met try again.

1 Like

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!


1 Like


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

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!


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?

In DMVPN Phase 2 configuration, EIGRP spoke routers do not automatically become neighbors because of the nature of the DMVPN architecture.

In a DMVPN Phase 2 configuration, the spoke routers use multipoint GRE tunnels to communicate with the hub router, and the hub router uses EIGRP to dynamically learn and propagate routes to the spoke routers. However, the spoke routers do not automatically become EIGRP neighbors because they do not have a direct physical connection with each other. Instead, the hub router acts as a proxy for the spoke routers, relaying EIGRP updates between the spokes.

Note that an EIGRP hello packet that establishes neighbor adjacency is a multicast packet. When a spoke router sends out a multicast packet, it sends it to the hub router over the multipoint GRE tunnel. The hub router then replicates the multicast packet and sends it out to all the other spoke routers that are connected to the same hub. This is achieved using NHRP mapping, which maps the tunnel IP address of the spoke router to its physical IP address. So because of this intervening of the hub, EIGRP adjacencies are not create.

Now if you want to enable EIGRP communication between the spokes in a DMVPN Phase 2 configuration, the hub router needs to be configured as an EIGRP stub router and the spoke routers need to be configured with the ip nhrp shortcut command. This allows the spoke routers to directly communicate with each other through the hub router, and enables EIGRP neighborship between the spoke routers.

I hope this has been helpful!


Hello, everyone!

When we disable split horizon, aren’t we creating the potential for a loop to occur in the DMVPN cloud?

Kind regards,

Hello David

Yes, you’re correct. When split horizon is disabled, it does indeed create a potential for a routing loop.

However, in a DMVPN scenario, we often need to disable split horizon on the hub to allow routes from one spoke to be advertised to another spoke via the hub. This is because all traffic in a DMVPN network goes through the hub router by default. The potential for a routing loop is a risk, but it’s mitigated by the inherent nature of a hub and spoke topology. In other words,

So, while disabling split horizon can theoretically increase the risk of a routing loop, in practice, with a correct DMVPN topology and configuration, the risk is essentially eliminated.

I hope this has been helpful!


Hello Laz

I appreciate your answer, very helpful! :slight_smile: I’ve a few additional inquiries, specifically related to Phase 2.

Initially, I wondered why didn’t the spokes send the multicast messages to eachother directly, why did all the routing protocol messages and updates have to go through the hub, which seemed counterintuitive, given that Phase 2 allows for direct spoke-to-spoke communication. However, I believe I now understand the reason behind it.

We could technically achieve direct spoke-to-spoke communication in terms of routing protocol messages by specifying the spoke’s IP address in the ip nhrp map multicast x.x.x.x command, correct? However, by doing so, we would have to configure this on every single spoke if we wanted direct spoke-to-spoke communication in this kind of scenario, so it’s for the best to just send it to the NHRP server who will relay it on.

Thank you


Hello David

Indeed, in Phase 2, the spokes don’t know how to reach each other directly until they first communicate through the hub. This is because the NHRP mappings are only created when the spokes communicate with the hub. Once the communication is established, the hub updates its NHRP database and the spokes can then communicate directly. But this dynamic creation of spoke-to-spoke tunnels occurs only with unicast traffic. Multicast traffic will not trigger NHRP to create a direct spoke-to-spoke tunnel. Multicast traffic will continue to be routed via the hub until a unicast packet triggers the creation. Take a look at this NetworkLessons note for more details.

As for the ip nhrp map multicast x.x.x.x command, you can use it in this fashion, however, it is generally not used to map multicast traffic to a specific spoke. If you had a topology with 10 spokes, you would have to issue the command for the IP address of every other spoke. When the command is used with multiple addresses, the system replicates the multicast packet for each address. The result is that multicast is sent to all of the mapped destinations essentially resulting in a broadcast. So beyond the fact that it is tedious to configure and maintain, it also defeats the purpose of multicast. More on this command can be found at this Cisco command reference.

The ip nhrp map multicast command should only be used to point to the hub informing NHRP that multicast packets should be sent there. The reason for this is to allow the hub to process and forward multicast packets centrally, efficiently, and appropriately within a DMVPN network.

I hope this has been helpful!