DMVPN - Phase 2 EIGRP neighbor adjacencies

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 it is possible to force spokes to become neighbors, although this is not recommended, as it disrupts the normal operation of DMVPN. You can enable EIGRP communication between the spokes in a DMVPN Phase 2 configuration by configuring the hub router as an EIGRP stub router. Additionally, 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.

A similar situation arises for OSPF adjacencies in a DMVPN Phase 2 arrangement. Conversely, BGP peerings can be established using DMVPN Phase 2 due to the nature of BGP and the way BGP peering takes place.

Links

https://networklessons.com/cisco/ccie-enterprise-infrastructure/dmvpn-phase-2-eigrp-routing