NHRP builds the tunnels; the routing protocol decides what flows through them, and DMVPN is unusually opinionated about how you run one. A hub that relays routes between spokes on a single multipoint interface trips over split horizon, next-hop handling, and OSPF's network-type machinery in ways a normal LAN never does. This article runs EIGRP named mode and OSPF point-to-multipoint over the same live Phase 3 lab (IOS XE 17.18, one hub, two spokes) and compares what lands in the RIB. It builds on the Phase 3 configuration walkthrough and slots into the DMVPN complete guide; deeper protocol background lives in the EIGRP and OSPF pillars.
Why the Hub Is a Special Case
On an ordinary router, routes learned on one interface get advertised out other interfaces, and loop-prevention rules like split horizon never bite. A DMVPN hub breaks that assumption: routes from SPOKE1 must be re-advertised out the same Tunnel0 they arrived on to reach SPOKE2. Distance-vector protocols explicitly forbid that (split horizon), and link-state protocols route around it with topology abstractions that were designed for broadcast LANs, not NBMA clouds. Every DMVPN routing design is a workaround for this one geometry problem, and the workarounds differ enough between protocols to change your architecture.
EIGRP: Two Knobs, Both on the Hub
EIGRP over DMVPN needs exactly two decisions, both under the hub's tunnel af-interface. First, split horizon must go, or spoke routes never reach other spokes:
router eigrp PINGLABZ
address-family ipv4 unicast autonomous-system 100
af-interface Tunnel0
no split-horizon
exit-af-interfaceSecond, next-hop-self, and this is the knob that encodes your DMVPN phase. With next-hop-self (the default), the hub rewrites itself as next hop for relayed routes. In our Phase 3 lab, SPOKE1 sees:
SPOKE1# show ip route eigrp
D 10.0.2.0/24 [90/102400640] via 10.0.0.1, 00:00:29, Tunnel0
D 10.0.100.0/24 [90/76800640] via 10.0.0.1, 00:00:29, Tunnel0With no next-hop-self (the Phase 2 design), the hub preserves the originating spoke's address, and the same route points spoke-to-spoke, captured from the same lab during its Phase 2 interlude:
SPOKE1# show ip route eigrp
D 10.0.2.0/24 [90/102400640] via 10.0.0.3, 00:00:15, Tunnel0Phase 3 wants the first behavior. Let the RIB point at the hub, let NHRP shortcuts override it per destination (the %/[NHO] mechanics are in the phase comparison), and reserve no next-hop-self for legacy Phase 2 clouds you have not migrated yet.
The payoff for keeping next-hop-self is summarization. A Phase 3 hub can collapse every spoke LAN into one advertisement (summary-address 10.0.0.0 255.0.0.0 under the af-interface) or even distribute just a default route, shrinking every spoke's table to a handful of entries regardless of how many sites exist. EIGRP also brings practical NBMA niceties: named mode's wide metrics handle the tunnel's low configured bandwidth sanely, hellos are unicast-replicated over the NHRP multicast maps automatically, and stub configuration on spokes (eigrp stub connected summary) protects the cloud from a branch router becoming transit during a hub flap. Named-mode syntax details are in the EIGRP guide.
OSPF: Fighting the Network Type
OSPF cannot simply relay routes with a rewritten next hop; its view of the world is a topology graph built per network type, so the choice of network type on Tunnel0 is the entire design. Two are defensible, and we ran the better one live. Configuration on every router:
interface Tunnel0
ip ospf network point-to-multipoint
router ospf 1
network 10.0.0.0 0.0.0.255 area 0Point-to-multipoint treats the NBMA cloud as a bundle of point-to-point links: no DR election, unicast-style adjacencies hub-to-spoke, 30-second hellos, and host routes for every tunnel endpoint. The hub's view:
HUB# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.2.1 0 FULL/ - 00:01:39 10.0.0.3 Tunnel0
10.0.1.1 0 FULL/ - 00:01:31 10.0.0.2 Tunnel0
HUB# show ip ospf interface Tunnel0
Process ID 1, Router ID 10.0.100.1, Network Type POINT_TO_MULTIPOINT, Cost: 1000
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5Note FULL with no DR/BDR column (the dash), and the interface cost of 1000 from the tunnel's default bandwidth. The spoke RIB shows the p2mp signature, /32 host routes for every endpoint with everything via the hub:
SPOKE1# show ip route ospf
O 10.0.0.1/32 [110/1000] via 10.0.0.1, 00:04:52, Tunnel0
O % 10.0.0.3/32 [110/2000] via 10.0.0.1, 00:04:44, Tunnel0
O 10.0.2.0/24 [110/2001] via 10.0.0.1, 00:04:44, Tunnel0
O 10.0.100.0/24 [110/1001] via 10.0.0.1, 00:04:52, Tunnel0Next hops at the hub are exactly what Phase 3 wants, and NHRP overrides them per flow; even the 10.0.0.3/32 host route carries the % marker from an active shortcut, and the traceroute went direct while OSPF pointed at the hub:
SPOKE1# traceroute 10.0.2.1 source Loopback1 numeric
1 10.0.0.3 2 msec * 2 msecThe alternative is network type broadcast: elect the hub DR (set spoke priority 0), keep 10-second hellos, no host routes. It works, but it is fragile by construction: a DR election on an NBMA cloud where spokes cannot see each other is a standing invitation for adjacency weirdness, and nothing stops a misconfigured spoke from trying to become DR. Avoid point-to-point on multipoint interfaces entirely (it can only form one adjacency), and treat p2mp as the default answer. Deeper network-type theory is in the OSPF guide.
OSPF's structural annoyance is that an area must share a single view: you cannot summarize inside area 0, so hub-side summarization toward spokes means putting the DMVPN cloud and the branches into their own area (or living with full tables). Flooding also scales with spoke count, and every spoke flap ripples LSAs across the cloud. These are manageable at dozens of spokes and painful at hundreds.
Timers, MTU, and Adjacency Gotchas
Three operational notes that bite regardless of protocol. First, multicast: adjacencies only form because NHRP replicates multicast hellos to mapped peers, so a spoke missing ip nhrp map multicast pings the hub fine but never forms a neighbor, which sends you hunting a routing problem that is actually NHRP (see troubleshooting DMVPN). Second, MTU: OSPF checks interface MTU in DBD exchange, so a tunnel MTU mismatch stalls adjacencies in EXSTART, one more reason to standardize ip mtu 1400 everywhere (background in GRE MTU and fragmentation). Third, convergence expectations differ: EIGRP over DMVPN converges in seconds with feasible successors, while OSPF p2mp's 30/120 timers mean a silent spoke death takes two minutes to detect unless you add BFD or tune hellos, and aggressive timers across hundreds of tunnels have their own CPU bill.
Summarization in Practice
Since summarization is the payoff of getting these designs right, here is what it looks like on each protocol. EIGRP summarizes per interface, so the hub collapses all site LANs toward the spokes in one line under the tunnel af-interface:
router eigrp PINGLABZ
address-family ipv4 unicast autonomous-system 100
af-interface Tunnel0
summary-address 10.0.0.0 255.0.0.0
exit-af-interfaceEvery spoke's RIB shrinks to one D route for the entire 10.0.0.0/8 plus its own connected prefixes, and Phase 3 shortcuts keep resolving the specifics on demand. EIGRP installs the customary Null0 discard route on the hub as loop protection. Watch one interaction: the summary also suppresses the specifics toward the spokes' own prefixes, so a spoke whose LAN falls inside the summary must not recursively route its own subnet at the hub; sane addressing (per-site blocks that do not overlap the summary boundary badly) avoids the problem. OSPF has no in-area summarization, so the equivalent design puts the DMVPN tunnel and branch LANs in a dedicated area and summarizes at the ABR with area 1 range 10.0.0.0 255.0.0.0, or leaks only a default into a stub/totally-stubby area, which is the cleanest OSPF-over-DMVPN pattern of all: spokes in a totally stubby area carry a default plus intra-area routes and nothing else.
Convergence Tuning: BFD and Timers
Default failure detection over DMVPN is slow (EIGRP holdtime 15 seconds on the tunnel, OSPF p2mp dead time 120 seconds), and tightening hello timers across hundreds of tunnels multiplies control plane load on the hub. BFD is the professional answer: hardware-independent sub-second detection with one session per neighbor, registered to the routing protocol.
interface Tunnel0
bfd interval 300 min_rx 300 multiplier 3
router eigrp PINGLABZ
address-family ipv4 unicast autonomous-system 100
af-interface Tunnel0
bfd
exit-af-interface(The OSPF equivalent is bfd under the process or ip ospf bfd per interface.) A 300ms/x3 profile detects a dead peer in under a second while surviving normal internet jitter; go slower (500ms or 1s intervals) for high-latency transports. Two cautions specific to DMVPN: BFD sessions ride the tunnel, so they tell you about overlay liveness, not which underlay component died; and hub CPU budgets matter, since a thousand spokes at 300ms is over three thousand BFD packets per second before anything useful happens. Scale the interval to the spoke count and let the routing protocol's own timers be the backstop.
Choosing, and What About BGP?
For a Cisco-only DMVPN, EIGRP named mode is the path of least resistance: two af-interface commands on the hub, free summarization, fast convergence, stub protection for branches. Choose OSPF p2mp when multi-vendor spokes or an existing OSPF backbone demand it, and accept the area-design homework. At very large scale (many hundreds to thousands of spokes), the industry answer shifts to iBGP with the hub as route reflector advertising a default, dynamic peer listeners, and per-spoke policy control; that design pairs naturally with Phase 3 summarization and is standard in DMVPN-based SD-WAN precursors. Our routing protocols over GRE article covers the single-tunnel fundamentals these designs build on.
Key Takeaways
The hub's geometry drives everything: relayed routes must exit the interface they entered, so EIGRP needs no split-horizon and a next-hop-self decision (keep it on for Phase 3, off only for Phase 2), while OSPF needs a network type chosen deliberately, with point-to-multipoint as the robust default over broadcast's fragile DR election. Phase 3 plus hub-side summarization is the scaling unlock, and it favors EIGRP or BGP because OSPF cannot summarize within an area. Whatever you run, remember the adjacency depends on NHRP multicast maps, the MTU must match, and the RIB pointing at the hub is correct, not broken, because NHRP shortcuts do the last-mile optimization. Full cluster map in the DMVPN complete guide.
