A parks department runs OSPF over DMVPN mGRE and needs stable adjacencies without treating the overlay like a broadcast LAN full of unexpected DR elections. Which approach is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
OSPF network type on mGRE is the seating chart: pick point-to-multipoint (typical for hub-spoke) so you are not electing a DR across a fake broadcast cloud over the Internet. Wrong network type means flapping adjacencies and parks WAN pain.
Full Explanation
OSPF over DMVPN requires selecting a network type that matches multipoint GRE hub-and-spoke reality. Point-to-multipoint is a common choice for a parks department because it forms adjacencies without fragile broadcast-segment DR/BDR assumptions that are brittle on dynamic Internet underlays. Network type is a first-class design decision for stable overlay OSPF.
Forcing OSPF broadcast on every spoke and relying on the highest router ID as a permanent DR across the Internet underlay invites adjacency and DR instability. Disabling OSPF hellos on the tunnel and using LDP between spokes confuses MPLS underlay tools with overlay IGP adjacency. Mapping OSPF areas one-to-one with MPLS RTs so adjacency follows VPN import policy mixes unrelated control planes.
Exam caveat: wrong OSPF network type on mGRE is a classic flap cause—pick point-to-multipoint (or another design-appropriate type) deliberately.
Operational check: set a consistent hub-spoke-friendly network type, verify FULL adjacencies without unexpected DR elections, and retest after adding parks spokes. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services.