DMVPN Phase 1 vs Phase 2 vs Phase 3: What Actually Changes

Ask what separates DMVPN Phase 1 from Phase 2 from Phase 3 and you will usually get a memorized answer: "Phase 1 is hub-and-spoke, Phase 2 adds spoke-to-spoke, Phase 3 adds redirects." True, and useless for the ENARSI exam or a real migration, because the phases differ in configuration details, routing protocol requirements, and what shows up in the RIB. So we did the migration for real: one lab (hub, two spokes, IOS XE 17.18), reconfigured live from Phase 1 to Phase 2 to Phase 3, with the routing table, NHRP cache, and traceroutes captured at each stop. This is the phase comparison the DMVPN complete guide summarizes in one card grid, expanded to full depth.

What "Phase" Actually Means

A phase is not negotiated, versioned, or displayed in any show command. It is a name for a combination of configuration choices, and the combination controls exactly one behavior: the path spoke-to-spoke traffic takes. Two things vary: whether spoke tunnels are point-to-point or multipoint GRE, and how next hops are handled (by the routing protocol in Phase 2, by NHRP in Phase 3). Everything else (registration, hub config, the overlay subnet) stays essentially the same across all three. Component background is in DMVPN explained.

Phase 1: Point-to-Point Spokes, Hub Forwards Everything

In Phase 1 only the hub runs mGRE. Each spoke is a plain GRE tunnel with a hardcoded destination, plus NHRP configuration used purely for registration:

interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp authentication PLZ123
 ip nhrp map 10.0.0.1 203.0.113.1
 ip nhrp map multicast 203.0.113.1
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1
 tunnel source Ethernet0/1
 tunnel destination 203.0.113.1
 tunnel key 100

The spoke's NHRP cache stays minimal forever, just the static hub entry:

SPOKE1# show ip nhrp
10.0.0.1/32 via 10.0.0.1
   Tunnel0 created 00:02:23, never expire
   Type: static, Flags:
   NBMA address: 203.0.113.1

With EIGRP running over the top (hub configured with no split-horizon so spoke routes reach other spokes), every remote prefix points at the hub, and spoke-to-spoke traffic transits it on every packet:

SPOKE1# show ip route eigrp
D        10.0.2.0/24 [90/102400640] via 10.0.0.1, 00:01:58, Tunnel0
D        10.0.100.0/24 [90/76800640] via 10.0.0.1, 00:02:04, Tunnel0

SPOKE1# traceroute 10.0.2.1 source Loopback1 numeric
  1 10.0.0.1 2 msec 2 msec 1 msec
  2 10.0.0.3 2 msec *  3 msec

Because a point-to-point tunnel can only ever send to the hub, the routing design is trivially free: summarize, filter, send a default route, nothing breaks. The costs are hub bandwidth (every spoke-to-spoke packet crosses it twice), hub CPU, and latency. Phase 1 is legitimate where spokes genuinely never talk to each other, and as the first stage of a migration, which is exactly how we use it here.

Phase 2: mGRE Spokes, Routing Protocol Preserves Next Hops

Migrating a spoke to Phase 2 is two interface commands (drop the fixed destination, go multipoint):

interface Tunnel0
 no tunnel destination
 tunnel mode gre multipoint

But mGRE alone changes nothing about forwarding; the routes still point at the hub. Phase 2's defining requirement lives in the routing protocol: the hub must advertise spoke prefixes with the originating spoke's tunnel address as next hop. For EIGRP that means no next-hop-self under the tunnel af-interface (plus the no split-horizon you already needed). The result in SPOKE1's RIB, captured seconds after the change:

SPOKE1# show ip route eigrp
D        10.0.2.0/24 [90/102400640] via 10.0.0.3, 00:00:15, Tunnel0
D        10.0.100.0/24 [90/76800640] via 10.0.0.1, 00:00:17, Tunnel0

That via 10.0.0.3 is the Phase 2 signature: the next hop for SPOKE2's LAN is SPOKE2's tunnel IP, not the hub. The first packet toward it triggers an NHRP resolution for 10.0.0.3, the spokes learn each other's underlay addresses, and a dynamic tunnel forms:

SPOKE1# show dmvpn
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 203.0.113.1            10.0.0.1    UP 00:00:59     S
     1 192.0.2.1              10.0.0.3    UP 00:00:00     D

SPOKE1# traceroute 10.0.2.1 source Loopback1 numeric
  1 10.0.0.3 2 msec *  2 msec

One hop, direct. So why did the industry abandon Phase 2? Because the trigger is the RIB, the RIB must contain every individual spoke prefix with its original next hop. Summarize at the hub and the specific next hops disappear into the summary; spokes lose the information needed to resolve each other and traffic quietly falls back to the hub (or worse, blackholes with OSPF designs). A thousand spokes means a thousand prefixes in every spoke's table. Phase 2 also forces awkward routing protocol constraints (OSPF broadcast mode with the hub winning DR election, EIGRP without summarization), which is a routing tax explored in routing over DMVPN.

Phase 3: NHRP Takes Over Next-Hop Discovery

Phase 3 keeps mGRE everywhere and moves the shortcut trigger from the routing protocol into NHRP with one command on each side:

! Hub
interface Tunnel0
 ip nhrp redirect
! Spokes
interface Tunnel0
 ip nhrp shortcut

The routing design reverts to boring: hub keeps next-hop-self (we re-enabled it in the lab), and summarization is not only allowed but encouraged. All routes point at the hub again:

SPOKE1# show ip route eigrp
D        10.0.2.0/24 [90/102400640] via 10.0.0.1, 00:00:29, Tunnel0

Now the hub watches for hairpin traffic (in and out the same tunnel interface). When SPOKE1 sends the first packets toward SPOKE2 through it, the hub forwards them and simultaneously sends SPOKE1 an NHRP Traffic Indication: "resolve this yourself." The spoke does, and installs the answer underneath the routing table. Two consecutive traceroutes catch the cutover mid-flight:

SPOKE1# traceroute 10.0.2.1 source Loopback1 numeric
  1 10.0.0.1 2 msec 1 msec 2 msec
  2 10.0.0.3 3 msec *  2 msec
SPOKE1# traceroute 10.0.2.1 source Loopback1 numeric
  1  *
    10.0.0.3 4 msec *

The mechanism is visible in three places. The NHRP cache gains a shortcut entry for the remote LAN prefix itself (not just the tunnel address), flagged nho:

SPOKE1# show ip nhrp
10.0.2.0/24 via 10.0.0.3
   Tunnel0 created 00:00:09, expire 00:09:50
   Type: dynamic, Flags: router used rib nho
   NBMA address: 192.0.2.1

The RIB shows the EIGRP route still pointing at the hub, with an NHRP next-hop override beside it (the % marker) and an H route for the peer's tunnel address:

SPOKE1# show ip route next-hop-override
H        10.0.0.3/32 is directly connected, 00:00:09, Tunnel0
D   %    10.0.2.0/24 [90/102400640] via 10.0.0.1, 00:00:57, Tunnel0
                     [NHO][90/255] via 10.0.0.3, 00:00:09, Tunnel0

And show dmvpn distinguishes the shortcut kinds: DT1 is the route-installed entry, DT2 the next-hop override:

SPOKE1# show dmvpn
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 203.0.113.1            10.0.0.1    UP 00:02:26     S
     2 192.0.2.1              10.0.0.3    UP 00:00:09   DT1
                              10.0.0.3    UP 00:00:09   DT2

Control plane and data plane are now decoupled: EIGRP could advertise nothing but a summary (or a plain default route) and shortcuts would still form, because NHRP resolution carries the real prefix information on demand. That is what lets Phase 3 hubs serve hundreds of spokes with tiny routing tables. The full configuration walkthrough is in DMVPN Phase 3 configuration on Cisco IOS XE, and the NHRP message mechanics are in the NHRP deep dive.

The Migration Path, Compressed

Since we just did it live, here is the entire Phase 1 to Phase 3 migration in order of operations. On each spoke: remove tunnel destination, set tunnel mode gre multipoint, add ip nhrp shortcut. On the hub: add ip nhrp redirect, keep no split-horizon, keep (or restore) next-hop-self, and start summarizing if the design allows. Each spoke can migrate independently while Phase 1 spokes continue working through the hub, which is what makes this migration doable during business hours: a Phase 1 spoke and a Phase 3 spoke coexist happily on the same hub, they just never build a direct tunnel to each other.

The Summarization Test: One Design Question That Separates the Phases

If you remember one discriminator, make it this one: what happens when the hub advertises a summary instead of specific prefixes? In Phase 1, nothing interesting; traffic already goes to the hub, the hub has the specifics, forwarding is unchanged. In Phase 2, disaster in slow motion: spokes lose the per-prefix next hops that triggered resolution, spoke-to-spoke traffic follows the summary to the hub, and your direct tunnels silently stop forming; with OSPF variants of the design you could even blackhole. In Phase 3, the summary is the design: traffic follows it to the hub, the hub's redirect teaches the source spoke the specific destination, and NHRP resolution supplies the granular information the routing protocol deliberately stopped carrying.

Push Phase 3 to its logical extreme and the hub advertises exactly one route: 0.0.0.0/0 over the tunnel. Every spoke's table holds a default via 10.0.0.1 plus its own connected routes, yet full spoke-to-spoke meshing still works, one NHRP resolution at a time. That single-default design is how DMVPN clouds reach thousands of spokes with routers whose RIBs would choke on a full table, and it only exists because Phase 3 moved next-hop discovery out of the control plane. It also collapses convergence scope: a spoke flapping in Toronto no longer churns the routing table of a spoke in Madrid that never talks to it.

Hub Failure Behavior Differs by Phase Too

The phases also answer "what breaks when the hub dies?" differently, which matters for redundancy design. In Phase 1, everything: the hub is the data path. In Phase 2 and 3, established spoke-to-spoke tunnels keep forwarding on their cached NHRP entries even with the hub down, degrading gracefully until holdtimes expire or new resolutions are needed; what you lose immediately is the ability to form new shortcuts and, usually, the routing control plane. This is why DMVPN redundancy focuses on the NHS: a second hub is one more ip nhrp nhs statement per spoke (with priority and cluster options controlling failover order), and dual-hub dual-cloud designs put each hub on its own tunnel interface and let routing metrics choose. Whatever the phase, spokes should treat NHS entries the way they treat default gateways: always have two.

Exam Traps Worth Rehearsing

Four distinctions ENARSI likes. First, ip nhrp shortcut goes on spokes and ip nhrp redirect goes on the hub (a spoke-only cloud never sends redirects; both commands on all routers is harmless and common in configs, but know which does what). Second, Phase 2 requires no next-hop-self; Phase 3 pointedly does not, and combining Phase 3 with preserved next hops mostly works but reintroduces Phase 2's summarization constraints for nothing. Third, the phase is per-tunnel-interface, not per-router, so a hub can serve different phases on different tunnels. Fourth, only Phase 1 uses tunnel destination on spokes; if you see it with tunnel mode gre multipoint in the same interface, the config is broken, not hybrid.

Key Takeaways

The phases answer one question three ways: how does spoke-to-spoke traffic flow? Phase 1 (p2p GRE spokes) sends it through the hub forever but leaves routing design unconstrained. Phase 2 (mGRE spokes, next hops preserved by the routing protocol) goes direct but forbids summarization because the RIB itself is the shortcut trigger. Phase 3 (mGRE plus redirect on the hub and shortcut on spokes) moves the trigger into NHRP, restoring summarization while keeping direct paths, visible as %/[NHO] overrides and H routes underneath an unchanged routing table. Deploy Phase 3 unless you have a documented reason not to. See the whole architecture in the DMVPN complete guide, or verify each phase's tunnels layer by layer with the GRE guide.