DMVPN - Phase 2 OSPF neighbor adjacencies

In DMVPN Phase 2 configuration, OSPF 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 OSPF to dynamically learn and propagate routes to the spoke routers. However, the spoke routers do not automatically become OSPF 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 OSPF updates between the spokes.

So by default, spokes can only “see” the hub and not each other. They are not aware of each other’s existence directly, and thus can’t form neighbor relationships or communicate directly with each other.

Now DMVPN Phase 2 uses NHRP to allow spokes to learn about each other and establish direct tunnels between themselves, bypassing the hub. However, the process to establish these direct tunnels involves the hub and NHRP. It is not automatic and requires the spokes to request the necessary information from the hub.

Note that routing protocols such as OSPF as well as EIGRP rely on the broadcast and Multicast capabilities of the underlying network to form adjacencies. Since the spokes don’t directly see each other and require the hub and NHRP to intervene to “simulate” a direct connection, this arrangement does not support the automatic discovery of neighbors using broadcast/multicast. Thus these routing protocols cannot see each other.

A similar case can be seen with EIGRP 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://forum.networklessons.com/t/dmvpn-phase-2-bgp-routing/1310/14?u=lagapides

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