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.
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 appreciate your answer, very helpful! 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.
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āve a few additional inquiries, specifically related to Phase 2.