DMVPN – Dynamic Multipoint VPN

1. What Is DMVPN and Why Was It Created?

DMVPN (Dynamic Multipoint VPN) is a Cisco-developed VPN architecture that addresses the scalability limitations of traditional point-to-point VPN designs. Defined using a combination of mGRE (Multipoint Generic Routing Encapsulation), NHRP (Next Hop Resolution Protocol), and IPsec, DMVPN allows a hub router to support hundreds or thousands of spoke routers using a single tunnel interface — and enables spokes to build direct encrypted tunnels to each other on demand, without any hub involvement once the tunnel is established.

Traditional hub-and-spoke VPNs require a separate point-to-point GRE tunnel and a separate IPsec crypto map entry for every spoke. Adding a new spoke means reconfiguring the hub. With DMVPN, adding a new spoke requires only configuration on the spoke itself — the hub requires no changes, making DMVPN highly scalable.

Feature	Traditional Point-to-Point VPN	DMVPN
Hub tunnel interfaces	One tunnel interface per spoke	One single mGRE tunnel interface for all spokes
Adding a new spoke	Hub must be reconfigured — new tunnel, new crypto map entry	Hub requires no changes — spoke self-registers via NHRP
Spoke-to-spoke traffic	All traffic must traverse the hub (hair-pinning)	Spokes can build direct tunnels (Phase 2/3) — bypasses hub
Spoke IP addresses	Must be static — crypto map requires known peer IPs	Spokes can have dynamic IP addresses (e.g., ISP-assigned DHCP) — NHRP resolves them dynamically
Scalability	Poor — grows linearly in config complexity with each spoke	Excellent — hundreds of spokes with minimal hub configuration
Configuration complexity	High — O(n) tunnel and IPsec entries on the hub	Low on hub — O(1); new spoke only requires spoke-side config

2. DMVPN Building Blocks

DMVPN is not a single protocol — it is a combination of three technologies working together. Understanding each component independently is essential before grasping how DMVPN works as a whole.

2.1 mGRE – Multipoint GRE

mGRE (Multipoint GRE) is an extension of standard point-to-point GRE that allows a single tunnel interface to accept and send traffic to multiple remote endpoints. In standard GRE, every tunnel is a one-to-one relationship — one source, one destination. mGRE removes the fixed destination, allowing the same interface to reach any number of peers.

Feature	Standard GRE	mGRE
Tunnel destination	Fixed — one specific remote IP address	Dynamic — no fixed destination; any peer can be reached
Peers per interface	One	Many — one interface serves all spokes
Cisco IOS mode	`tunnel mode gre point-to-point`	`tunnel mode gre multipoint`
Destination resolution	Statically configured	Dynamically resolved via NHRP

2.2 NHRP – Next Hop Resolution Protocol

NHRP (Next Hop Resolution Protocol), defined in RFC 2332, is the protocol that allows DMVPN routers to discover each other's public (physical) IP addresses from their private (tunnel) IP addresses. It works similarly to ARP — but instead of resolving Layer 3 IP addresses to Layer 2 MAC addresses, NHRP resolves tunnel IP addresses to the real (NBMA) IP addresses used to route packets across the internet.

NHRP Role	Router Type	Behaviour
NHS (Next Hop Server)	Hub router	Maintains the NHRP database — a mapping of each spoke's tunnel IP address to its public NBMA IP address. All spokes register with the hub NHS when they come online.
NHC (Next Hop Client)	Spoke router	Registers its own tunnel IP → NBMA IP mapping with the NHS. Sends NHRP Resolution Requests to the hub to discover other spokes' NBMA addresses when direct tunnels are needed.

2.3 IPsec – Encryption Layer

IPsec provides encryption and authentication for all traffic flowing through the DMVPN tunnels. In DMVPN, IPsec is applied as an IPsec profile directly on the tunnel interface (rather than using a traditional crypto map), which allows dynamic tunnel creation without per-peer pre-configuration. Both hub-to-spoke and spoke-to-spoke tunnels can be automatically protected with IPsec.

See IPsec VPN Concepts for full detail on IKE Phase 1, Phase 2, ESP, and transform sets.

3. DMVPN Topology – Hub and Spoke

DMVPN is built on a hub-and-spoke topology. The hub router acts as the central point — it has a static public IP address, maintains the NHRP database, and provides the initial path for all spoke-to-spoke communication. Spokes may have dynamic public IP addresses (common in branch deployments where the ISP assigns IPs via DHCP).

DMVPN Role	Characteristics	Typical Deployment
Hub Router	Static public IP address; NHS for NHRP; single mGRE tunnel interface; no configuration changes needed when spokes are added	Headquarters data centre, regional hub, or cloud edge router
Spoke Router	Can have dynamic public IP; NHC for NHRP; registers with hub NHS on startup; builds hub-to-spoke permanent tunnel; builds spoke-to-spoke dynamic tunnels on demand (Phase 2/3)	Branch offices, remote sites, or cloud VPCs

3.1 DMVPN Address Structure

DMVPN uses two types of IP addresses on each router. Understanding which address is the tunnel IP and which is the physical (NBMA) IP is fundamental to understanding NHRP operation:

Address Type	Also Called	Location	Purpose
Tunnel IP address	Inner address, virtual address	Assigned to the tunnel interface (e.g., 10.0.0.1/24)	Used for routing — the address that routing protocols (EIGRP, OSPF) use as the next hop
NBMA IP address	Physical address, outer address, public IP	Assigned to the physical WAN interface (e.g., 203.0.113.1)	The real internet-routable IP — used to route the encapsulated GRE/IPsec packet across the underlay network

4. DMVPN Phase 1 – Hub and Spoke Only

DMVPN Phase 1 is the simplest DMVPN deployment. In this phase, all spoke-to-spoke traffic must be routed through the hub — there is no direct spoke-to-spoke tunnel capability. Phase 1 essentially replaces multiple static point-to-point GRE tunnels with a single mGRE interface on the hub.

4.1 Phase 1 Traffic Flow

Traffic Type	Path	Notes
Hub to Spoke	Hub → direct tunnel → Spoke	Hub looks up the spoke's NBMA address in its NHRP database and sends directly
Spoke to Hub	Spoke → direct tunnel → Hub	Spoke has the hub's NBMA IP statically configured as the NHS — tunnel to hub is always pre-established
Spoke to Spoke	Spoke A → Hub → Spoke B (hair-pinning)	No direct spoke-to-spoke tunnel — all inter-spoke traffic traverses the hub twice, consuming hub bandwidth and adding latency

4.2 Phase 1 Characteristics

Characteristic	Phase 1 Behaviour
Spoke-to-spoke tunnels	None — not supported; all inter-spoke traffic via hub
Hub mGRE tunnel	Hub uses mGRE; spokes may use point-to-point GRE pointing to hub, or mGRE (for Phase 2/3 readiness)
Routing protocol behaviour	Standard hub-and-spoke routing — spoke routes point to hub as next hop; hub redistributes or summarises spoke routes
Scalability benefit vs P2P VPN	Hub config is O(1) — same regardless of number of spokes; only spoke-side config grows
When to use	When spoke-to-spoke traffic is minimal or unnecessary; simple hub-and-spoke WAN replacement

5. DMVPN Phase 2 – Spoke-to-Spoke Tunnels

DMVPN Phase 2 adds the ability for spokes to build direct spoke-to-spoke tunnels on demand, bypassing the hub for inter-spoke traffic. This dramatically reduces hub bandwidth consumption and latency for spoke-to-spoke flows.

5.1 Phase 2 Spoke-to-Spoke Tunnel Creation

Step	Action	Protocol
1	Spoke A has traffic destined for Spoke B's subnet. Spoke A does not know Spoke B's NBMA (public IP) address yet — the first packet is forwarded to the hub via the existing hub-to-spoke tunnel.	Routing (EIGRP/OSPF/BGP)
2	Spoke A sends an NHRP Resolution Request to the hub NHS asking: "What is the NBMA address of the tunnel endpoint for Spoke B's IP?"	NHRP
3	The hub NHS looks up Spoke B's NBMA address in its NHRP database (where Spoke B registered on startup) and sends an NHRP Resolution Reply back to Spoke A with Spoke B's public IP.	NHRP
4	Spoke A now has Spoke B's NBMA address and builds a direct mGRE tunnel to Spoke B. If IPsec is configured, IKE Phase 1 and Phase 2 are negotiated between Spoke A and Spoke B directly.	mGRE + IPsec (IKE)
5	Subsequent traffic from Spoke A to Spoke B flows through the direct tunnel — the hub is not involved.	GRE + IPsec
6	The direct spoke-to-spoke tunnel is temporary — it is torn down after a period of inactivity (default hold timer expiry). It is rebuilt on demand when traffic flows again.	NHRP hold timer

5.2 Phase 2 Routing Constraint

Phase 2 introduces a critical routing requirement: the hub must not summarise or change the next-hop of spoke routes when advertising them to other spokes. If the hub summarises or changes the next-hop to itself, spokes will never trigger NHRP resolution for direct spoke-to-spoke tunnels — they will think the hub is the next hop for all destinations.

Routing Protocol	Phase 2 Requirement	Configuration Note
EIGRP	Hub must not summarise spoke routes; hub must not change next-hop	Use `no ip next-hop-self eigrp` on the hub tunnel interface to preserve the original spoke next-hop in EIGRP updates
OSPF	Tunnel interface must be in a non-broadcast or point-to-multipoint network type to allow correct DR/BDR election and next-hop preservation	Use `ip ospf network point-to-multipoint` on the tunnel interface; avoid broadcast network type on hub (which elects hub as DR and changes next-hop)
BGP	Hub must not change next-hop for iBGP routes to spokes	Use `next-hop-unchanged` or configure route-reflector to preserve original next-hop

6. DMVPN Phase 3 – Hierarchical and Optimised

DMVPN Phase 3 builds on Phase 2 by adding NHRP Redirect and NHRP Shortcut mechanisms that allow the hub to intelligently redirect spoke-to-spoke traffic and allow route summarisation on the hub — removing the Phase 2 next-hop preservation constraint.

6.1 Phase 3 Mechanism

Step	Action	Phase 3 Feature Used
1	Spoke A sends traffic to Spoke B — first packet goes to the hub (because the hub advertises a summary route covering all spoke subnets)	Hub route summarisation (now permitted in Phase 3)
2	The hub forwards the packet toward Spoke B and simultaneously sends an NHRP Redirect message back to Spoke A, telling it: "You should contact Spoke B directly."	NHRP Redirect (hub sends to Spoke A)
3	Spoke A receives the NHRP Redirect and sends an NHRP Resolution Request directly to Spoke B asking for its NBMA address.	NHRP Resolution Request
4	Spoke B responds with an NHRP Resolution Reply containing its NBMA address. Spoke A installs a NHRP Shortcut (a host route) in its routing table pointing directly to Spoke B.	NHRP Shortcut route installed on Spoke A
5	Subsequent traffic from Spoke A to Spoke B uses the direct tunnel — bypassing the hub completely.	Direct mGRE + IPsec spoke-to-spoke tunnel

6.2 Phase 1 vs Phase 2 vs Phase 3 Comparison

Feature	Phase 1	Phase 2	Phase 3
Spoke-to-spoke tunnels	✘ No — all via hub	✔ Yes — direct after NHRP resolution	✔ Yes — direct after NHRP Redirect + Shortcut
Hub route summarisation	✔ Yes — allowed	✘ No — hub cannot summarise; must preserve next-hop	✔ Yes — allowed again; NHRP Redirect handles redirection
NHRP feature used	Registration only	Registration + Resolution Request/Reply	Registration + Resolution + Redirect + Shortcut
First packet path	Always via hub	Via hub, then direct after NHRP	Via hub (hub forwards + sends Redirect), then direct
Hub configuration	`ip nhrp map multicast dynamic`	`ip nhrp map multicast dynamic`	`ip nhrp redirect` added on hub
Spoke configuration	Standard NHRP registration	Standard NHRP registration	`ip nhrp shortcut` added on spoke
Routing complexity	Low — standard hub-spoke routing	Medium — next-hop must be preserved end-to-end	Low — summarisation permitted; NHRP handles shortcuts
Scalability	Good	Good	Best — combines summarisation with direct tunnels

7. NHRP Operation in Detail

NHRP is the glue that holds DMVPN together. The following table summarises the key NHRP message types and the NHRP database entries that result:

NHRP Message	Sender	Recipient	Purpose
NHRP Registration Request	Spoke (NHC)	Hub (NHS)	Spoke announces its tunnel IP → NBMA IP mapping to the hub on startup or when NBMA IP changes (dynamic IP spokes)
NHRP Registration Reply	Hub (NHS)	Spoke (NHC)	Hub acknowledges the registration; provides hold time for the entry
NHRP Resolution Request	Spoke A	Hub (NHS) — relayed to Spoke B in Phase 3	Spoke A asks: "What is the NBMA address of the router that owns tunnel IP X?"
NHRP Resolution Reply	Hub (Phase 2) or Spoke B directly (Phase 3)	Spoke A	Provides the NBMA address of Spoke B — allows Spoke A to build a direct tunnel
NHRP Redirect	Hub	Spoke A	Phase 3 only — hub tells Spoke A to contact Spoke B directly rather than routing through the hub
NHRP Purge	Hub or Spoke	Peer	Removes a stale NHRP cache entry — used when a spoke's NBMA IP changes (dynamic IP) so other routers remove the old mapping

7.1 NHRP Hold Time and Cache

Every NHRP registration and resolution entry has a hold time — the number of seconds the entry remains valid. Before the hold time expires, the NHC must re-register to keep the entry alive. NHRP cache entries on spokes for spoke-to-spoke tunnels are typically much shorter (seconds to minutes) than hub registrations (hours).

NHRP Entry Type	Default Hold Time	Cisco IOS Command
Spoke-to-hub registration	7200 seconds (2 hours)	`ip nhrp holdtime 7200`
Spoke-to-spoke dynamic entry	120–300 seconds	Set by the Resolution Reply hold time

8. Routing Protocols over DMVPN

Any dynamic routing protocol can run over a DMVPN tunnel, but each has specific considerations depending on the DMVPN phase and the NBMA network type. EIGRP is the most commonly paired routing protocol with DMVPN in Cisco environments.

Routing Protocol	DMVPN Phase 1	DMVPN Phase 2	DMVPN Phase 3	Key Configuration Note
EIGRP	Works well — hub-and-spoke routing	Requires `no ip next-hop-self eigrp` on hub tunnel interface to preserve spoke next-hops in updates	Standard EIGRP config works — summarisation permitted; NHRP Redirect handles shortcuts	Most common DMVPN routing protocol; EIGRP stub on spokes reduces unnecessary query propagation
OSPF	Works — use `point-to-multipoint` network type	Use `point-to-multipoint`; avoid broadcast type which changes next-hop to hub (DR)	Use `point-to-multipoint` or `point-to-multipoint non-broadcast`	Avoid default broadcast network type on DMVPN — it elects a DR/BDR (hub wins) and changes next-hop, breaking Phase 2
BGP	Works — standard iBGP mesh or route-reflector	Hub must preserve next-hop with `next-hop-unchanged` or use eBGP between spokes	Flexible — summarisation allowed; use with route-reflector for scale	BGP is increasingly used in large-scale DMVPN (SD-WAN-like designs)

9. DMVPN Configuration Overview

The following shows the key components of a DMVPN Phase 3 configuration. For the complete step-by-step lab with all phases, see the DMVPN Phase 1, 2 & 3 Lab.

9.1 Hub Router Configuration

! ===== Hub – DMVPN Phase 3 =====

! Step 1: Configure the ISAKMP policy (IKE Phase 1) for IPsec
Hub(config)# crypto isakmp policy 10
Hub(config-isakmp)# encryption aes 256
Hub(config-isakmp)# hash sha256
Hub(config-isakmp)# authentication pre-share
Hub(config-isakmp)# group 14
Hub(config-isakmp)# exit
Hub(config)# crypto isakmp key DMVPN_KEY address 0.0.0.0 0.0.0.0   ! Wildcard — any peer

! Step 2: Configure the IPsec transform set and profile
Hub(config)# crypto ipsec transform-set DMVPN_TS esp-aes 256 esp-sha256-hmac
Hub(cfg-crypto-trans)# mode transport                             ! Transport mode for GRE
Hub(cfg-crypto-trans)# exit
Hub(config)# crypto ipsec profile DMVPN_PROFILE
Hub(ipsec-profile)# set transform-set DMVPN_TS
Hub(ipsec-profile)# exit

! Step 3: Configure the mGRE tunnel interface
Hub(config)# interface Tunnel0
Hub(config-if)# ip address 10.0.0.1 255.255.255.0              ! Tunnel (inner) IP
Hub(config-if)# tunnel source GigabitEthernet0/0               ! Physical WAN interface
Hub(config-if)# tunnel mode gre multipoint                     ! mGRE — key DMVPN command
Hub(config-if)# tunnel key 12345                               ! Optional tunnel key
Hub(config-if)# tunnel protection ipsec profile DMVPN_PROFILE  ! Apply IPsec
Hub(config-if)# ip nhrp network-id 1                          ! NHRP domain ID
Hub(config-if)# ip nhrp map multicast dynamic                  ! Dynamic multicast mapping
Hub(config-if)# ip nhrp redirect                              ! Phase 3: enable redirect
Hub(config-if)# ip ospf network point-to-multipoint           ! Or EIGRP/BGP as needed
Hub(config-if)# exit

9.2 Spoke Router Configuration

! ===== Spoke – DMVPN Phase 3 =====

! Steps 1–2: Same ISAKMP and IPsec profile as hub (must match)

! Step 3: Configure the mGRE tunnel interface on the spoke
Spoke(config)# interface Tunnel0
Spoke(config-if)# ip address 10.0.0.2 255.255.255.0           ! Spoke tunnel IP
Spoke(config-if)# tunnel source GigabitEthernet0/0            ! Spoke WAN interface
Spoke(config-if)# tunnel mode gre multipoint
Spoke(config-if)# tunnel key 12345
Spoke(config-if)# tunnel protection ipsec profile DMVPN_PROFILE
Spoke(config-if)# ip nhrp network-id 1
Spoke(config-if)# ip nhrp nhs 10.0.0.1                       ! Hub tunnel IP = NHS address
Spoke(config-if)# ip nhrp map 10.0.0.1 203.0.113.1           ! Hub tunnel IP → NBMA IP
Spoke(config-if)# ip nhrp map multicast 203.0.113.1           ! Multicast via hub
Spoke(config-if)# ip nhrp shortcut                           ! Phase 3: enable shortcut
Spoke(config-if)# ip ospf network point-to-multipoint
Spoke(config-if)# exit

10. DMVPN Scalability Benefits

The scalability advantage of DMVPN over traditional VPN designs becomes dramatic at large scale. The following comparison illustrates the configuration and operational complexity for a network with N spoke sites:

Metric	Traditional P2P GRE + IPsec	DMVPN
Hub tunnel interfaces	N (one per spoke)	1 (single mGRE interface)
Hub crypto map entries	N	0 (dynamic IPsec profile — no static entries)
Hub config lines for 100 spokes	~800–1000 lines	~20–30 lines (same regardless of spoke count)
Adding a new spoke	Hub must add tunnel interface + crypto ACL + crypto map entry	Hub: no changes. Spoke: add tunnel interface + NHRP NHS config
Spoke dynamic IP support	No — crypto map requires static peer IP	Yes — NHRP registers any IP dynamically
Spoke-to-spoke latency	Double the WAN RTT (hub hair-pin) + hub CPU overhead	Direct tunnel RTT (Phase 2/3) after initial NHRP resolution
Hub bandwidth for S-to-S traffic	All inter-spoke traffic traverses hub twice	Phase 2/3: inter-spoke traffic bypasses hub completely

11. DMVPN Verification Commands

Command	Output / Purpose
`show dmvpn`	Overview of all DMVPN tunnels — peer state (NHRP state: INTF, IKE, IPSEC, UP), peer tunnel IP, NBMA address, and time since registration; the primary DMVPN health command
`show dmvpn detail`	Detailed per-peer DMVPN information — NHRP flags, IPsec SA state, interface statistics, and NHRP resolution entries
`show ip nhrp`	NHRP cache table — lists all known tunnel IP → NBMA IP mappings; shows entry type (static, dynamic, NHRP shortcut) and expiry time
`show ip nhrp detail`	Verbose NHRP cache including flags (registered, used, router) and which interface the entry arrived on
`show ip route`	Routing table — NHRP shortcut entries appear as `H` routes; verify that EIGRP/OSPF routes point to correct next-hops through the tunnel
`show crypto isakmp sa`	IKE Phase 1 SAs — verify that spoke IPsec sessions are in QM_IDLE state (established)
`show crypto ipsec sa`	IPsec Phase 2 SAs — packet encap/decap counters per peer; confirms traffic is being encrypted through the tunnels
`show interface Tunnel0`	Tunnel interface status — up/up state, MTU, packet counts; line protocol down indicates NHRP or routing issue
`debug nhrp`	Real-time NHRP messages — registration, resolution requests/replies, and redirect messages; essential for Phase 2/3 spoke-to-spoke troubleshooting
`debug dmvpn all`	Comprehensive DMVPN debug — combines NHRP, crypto, and tunnel events; use with caution in production

12. DMVPN Quick-Reference Summary

DMVPN Concept	Key Fact
Full name	Dynamic Multipoint VPN
Three building blocks	mGRE + NHRP + IPsec
mGRE advantage	One tunnel interface on hub serves all spokes (vs one per spoke in P2P GRE)
NHRP purpose	Resolves tunnel IP → NBMA (public) IP; allows dynamic IP spokes
Hub NHRP role	NHS (Next Hop Server) — maintains the NHRP mapping database
Spoke NHRP role	NHC (Next Hop Client) — registers with hub; queries for other spokes
Phase 1	Hub-and-spoke only — all inter-spoke traffic via hub; no direct spoke tunnels
Phase 2	Direct spoke-to-spoke tunnels via NHRP resolution; hub cannot summarise routes (next-hop must be preserved)
Phase 3	Direct spoke-to-spoke tunnels via NHRP Redirect + Shortcut; hub summarisation permitted; most scalable
Phase 3 hub command	`ip nhrp redirect`
Phase 3 spoke command	`ip nhrp shortcut`
EIGRP Phase 2 fix	`no ip next-hop-self eigrp` on hub tunnel interface
OSPF on DMVPN	Use `ip ospf network point-to-multipoint` — avoid broadcast type
Spoke dynamic IP	Fully supported — NHRP registers whatever IP the spoke has
Primary verification command	`show dmvpn`
NHRP shortcut route code	`H` in the routing table

Test Your Knowledge – DMVPN Quiz

1. What are the three core technologies that combine to form DMVPN?

A. OSPF, IPsec, and SSL B. L2TP, IKEv2, and BGP C. mGRE, NHRP, and IPsec D. GRE, MPLS, and AH

Correct answer is C. DMVPN is built on three complementary technologies: mGRE (Multipoint GRE) provides a single tunnel interface that can reach multiple peers; NHRP (Next Hop Resolution Protocol) dynamically maps tunnel IP addresses to NBMA (public) IP addresses, enabling spoke discovery without static configuration; IPsec encrypts and authenticates all traffic flowing through the tunnels using an IPsec profile on the tunnel interface.

2. What is the primary advantage of mGRE over standard point-to-point GRE in a hub-and-spoke VPN?

A. mGRE provides stronger encryption than standard GRE B. A single mGRE tunnel interface on the hub can communicate with any number of spoke peers, eliminating the need for one tunnel interface per spoke C. mGRE supports IPv6 while standard GRE only supports IPv4 D. mGRE automatically configures IPsec without ISAKMP negotiation

Correct answer is B. Standard GRE is point-to-point — one source, one fixed destination. In a traditional hub-and-spoke VPN with 100 spokes, the hub needs 100 separate tunnel interfaces. mGRE removes the fixed destination requirement, allowing a single tunnel interface to dynamically reach any number of remote endpoints. Combined with NHRP (which resolves destination IP addresses on demand), the hub needs just one mGRE tunnel interface regardless of how many spokes exist.

3. In DMVPN, what role does NHRP play, and which router acts as the NHS?

A. NHRP provides encryption; all spokes act as NHS B. NHRP is the routing protocol used to exchange spoke subnet routes; the hub acts as DR C. NHRP provides QoS markings for DMVPN traffic; each spoke is its own NHS D. NHRP resolves tunnel IP addresses to NBMA (public) IP addresses — like ARP but for overlay-to-underlay mapping. The hub acts as the NHS (Next Hop Server), maintaining registrations from all spokes (NHCs).

Correct answer is D. NHRP solves the core DMVPN problem: how does a spoke know the public IP of another spoke when spokes may have dynamic IPs and there is no static configuration between them? Every spoke (NHC — Next Hop Client) registers its tunnel IP → public NBMA IP mapping with the hub NHS on startup. When a spoke needs to reach another spoke directly, it queries the hub NHS which replies with the target's NBMA address — enabling direct tunnel establishment.

4. In DMVPN Phase 1, how does traffic flow between two spoke sites?

A. All inter-spoke traffic is routed through the hub (hair-pinned) — no direct spoke-to-spoke tunnels exist in Phase 1 B. Traffic flows directly between spokes after an NHRP Resolution Request C. Spokes communicate via MPLS labels through the provider network D. Phase 1 does not support spoke-to-hub traffic — only spoke-to-spoke

Correct answer is A. DMVPN Phase 1 is a pure hub-and-spoke design. All inter-spoke traffic must pass through the hub — this is called hair-pinning. Spoke A sends to the hub, the hub decapsulates and re-encapsulates for Spoke B. This consumes hub CPU and bandwidth and adds latency equal to twice the hub-to-spoke RTT. Phase 2 and Phase 3 solve this by enabling direct spoke-to-spoke tunnels.

5. Why must the hub NOT summarise routes when using DMVPN Phase 2 with EIGRP?

A. EIGRP does not support route summarisation over GRE tunnels B. Summarisation causes NHRP registration failures on the hub C. If the hub summarises or changes the next-hop of spoke routes, other spokes will forward inter-spoke traffic to the hub (thinking it is the next hop) and never trigger NHRP resolution for a direct spoke-to-spoke tunnel D. Summarisation prevents spokes from registering with the NHS

Correct answer is C. In DMVPN Phase 2, a spoke triggers NHRP resolution only when the routing table shows a specific next-hop address that is a directly reachable tunnel peer (another spoke). If the hub summarises routes or uses next-hop-self, the spoke's routing table shows the hub as the next hop for all destinations — the spoke never realises there is a direct path to the other spoke and never sends an NHRP Resolution Request. The fix is no ip next-hop-self eigrp on the hub, which preserves the original spoke tunnel IP as the next-hop in EIGRP updates.

6. What are NHRP Redirect and NHRP Shortcut, and which DMVPN phase introduces them?

A. NHRP Redirect is a Phase 1 feature that allows the hub to redirect spoke registrations to a backup hub B. Phase 3 features — NHRP Redirect is sent by the hub to tell a spoke to contact another spoke directly; NHRP Shortcut is a host route installed by the spoke for direct spoke-to-spoke forwarding, allowing hub route summarisation C. Phase 2 features — NHRP Redirect replaces the Registration Reply; NHRP Shortcut is the NHRP database entry on the hub D. These are IPsec features, not NHRP — they accelerate IKE Phase 1 negotiation between spokes

Correct answer is B. These are Phase 3 innovations. When the hub receives inter-spoke traffic, it forwards the packet to the destination spoke AND sends an NHRP Redirect to the originating spoke saying "contact the destination directly." The originating spoke then resolves the destination's NBMA address and installs an NHRP Shortcut — a /32 host route (marked H in the routing table) that points directly to the destination spoke. This allows the hub to use route summarisation (impossible in Phase 2) while still enabling direct spoke-to-spoke tunnels.

7. A spoke router has a dynamically assigned public IP address from its ISP. Is DMVPN compatible with this deployment?

A. No — DMVPN requires static public IP addresses on all routers including spokes B. No — dynamic IPs are only supported in Phase 3, not Phase 1 or 2 C. Yes, but only if the spoke uses a DDNS service to update the hub's static configuration D. Yes — NHRP registration is dynamic; when the spoke comes online it registers its current public IP with the hub NHS regardless of whether that IP is static or dynamic

Correct answer is D. This is one of DMVPN's major advantages over traditional P2P VPN. Because NHRP registration is performed dynamically by the spoke on startup, the spoke's NBMA (public) IP address does not need to be known in advance by the hub or any other spoke. When the spoke connects to its ISP and receives a DHCP-assigned address, it immediately registers that address with the hub NHS. All three DMVPN phases support dynamic spoke IP addresses — the hub only requires a static public IP (it is the NHS that all spokes must be able to reach).

8. What is the Cisco IOS command to verify the state of DMVPN tunnels and see whether spokes are in the UP state?

A. show dmvpn — displays peer state (INTF, IKE, IPSEC, UP), peer tunnel IPs, NBMA addresses, and registration time B. show ip tunnel — shows all GRE tunnel interfaces and their current state C. show crypto isakmp sa — the primary DMVPN health command D. show ip nhrp brief — the only command that shows DMVPN peer states

Correct answer is A. show dmvpn is the primary DMVPN health verification command. Its output shows each NHRP peer with its tunnel IP, NBMA IP, and current state. The state field cycles through: INTF (interface established), IKE (IKE negotiation in progress), IPSEC (IPsec SA being established), UP (fully operational). A peer stuck in IKE indicates IPsec negotiation failure; stuck in INTF indicates NHRP registration not yet completed. show ip nhrp is also important but shows the NHRP database, not the overall tunnel health summary.

9. Why is `ip ospf network point-to-multipoint` recommended on DMVPN tunnel interfaces instead of the default broadcast network type?

A. The broadcast network type does not support OSPF hello packets over GRE tunnels B. Point-to-multipoint disables OSPF authentication which is not compatible with DMVPN IPsec C. With broadcast type, the hub becomes OSPF DR and advertises spoke routes with itself as next-hop — breaking Phase 2 spoke-to-spoke tunnels. Point-to-multipoint preserves the original spoke next-hop in LSAs. D. Point-to-multipoint is required because OSPF does not support multicast over mGRE interfaces

Correct answer is C. With OSPF broadcast network type on the DMVPN tunnel, OSPF elects a DR (the hub almost always wins due to higher priority or router ID). The hub DR then advertises all spoke routes in LSAs with itself as the next-hop — exactly the same problem as EIGRP next-hop-self. Spokes see the hub as the next-hop for all destinations and never trigger NHRP resolution for direct tunnels. OSPF point-to-multipoint does not elect a DR, and each router advertises its own host route with itself as next-hop — preserving spoke next-hops correctly for Phase 2 spoke-to-spoke tunnel triggering.

10. You are troubleshooting a DMVPN Phase 2 network. `show dmvpn` shows all spokes as UP. However, `show ip route` on Spoke A shows the hub as the next-hop for all other spoke subnets, and no direct tunnels are forming to other spokes. What is the most likely cause?

A. The IPsec transform set is mismatched between spoke routers B. The hub is advertising spoke routes with itself as the next-hop (next-hop-self is active) — add no ip next-hop-self eigrp on the hub tunnel interface so spokes see each other's tunnel IPs as direct next-hops C. The spokes have not configured ip nhrp shortcut — required for spoke-to-spoke tunnels D. DMVPN Phase 2 only supports spoke-to-spoke tunnels when the hub has two WAN interfaces

Correct answer is B. This is the classic DMVPN Phase 2 misconfiguration. NHRP resolution is only triggered when Spoke A's routing table shows a specific spoke tunnel IP as the next-hop for a destination — this is what signals "I should build a direct tunnel to that spoke." If the hub is advertising all spoke routes with itself as the next-hop (default EIGRP behaviour), Spoke A always routes via the hub and never queries NHRP for a direct path. The fix is no ip next-hop-self eigrp <AS> on the hub's tunnel interface — this preserves the originating spoke's tunnel IP as the next-hop in EIGRP updates. Note: ip nhrp shortcut is a Phase 3 command, not required for Phase 2.

← Back to Home