Protocol Atlas

OVERLAY · overlay · reviewed

DMVPN

Dynamic Multipoint VPN

mGRE plus NHRP plus (usually) IPsec: spokes register with a hub, and Phase 3 builds on-demand spoke-to-spoke shortcuts from NHRP redirect and shortcut switching.

Presenter modeEmbed this figure

Protocol OverviewRFC 2332 · PROPOSED STANDARD · April 1998Structure of a GRE Encapsulated PacketRFC 2784 · PROPOSED STANDARD · March 2000Internet Header FormatRFC 791 · INTERNET STANDARD · September 1981

Why it exists

A full mesh of GRE/IPsec tunnels does not scale. DMVPN keeps a hub for control and registration while letting spokes build direct data paths when traffic needs them. Cisco IOS XE 17.x — Dynamic Multipoint VPN §Information About Dynamic Multipoint VPN

DMVPN is a design, not a single protocol. Diagnosing “DMVPN is down” means naming which layer failed: underlay, NHRP, IPsec, or overlay routing.

Spoke registers with the hub

Each spoke maps the hub’s tunnel address to a public NBMA address, registers via NHRP, and builds an mGRE tunnel protected by IPsec. The hub learns spoke underlay addresses dynamically.

Spoke1Spoke2Underlay · public IPHub · NHSOne mGRE for all spokesTunnel: mGRE
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
Spoke1router—
Spoke2router—
Underlay · public IPcloud—
Hub · NHSrouterTunnel: mGRE
Spoke1 — Underlay · public IPlinkup
Spoke2 — Underlay · public IPlinkup
Underlay · public IP — Hub · NHSlinkup
1 / 3

The hub runs a multipoint GRE tunnel. One interface serves every spoke. Outer packets are ordinary IPv4 toward the underlay; GRE is protocol 47 in the IPv4 header.

What changed

  • Outer IPv4 · proto 47: Spoke1 → Hub · NHS
  • Hub · NHS: Tunnel → mGRE
  • One mGRE for all spokes

How it works

Multipoint GRE gives the hub one tunnel interface for every spoke. GRE rides inside IPv4 as protocol 47; IPsec commonly encrypts that GRE. Structure of a GRE Encapsulated PacketRFC 2784 · PROPOSED STANDARD · March 2000

NHRP lets a spoke register its NBMA address with the hub and later resolve another spoke’s underlay address for a shortcut. Protocol OverviewRFC 2332 · PROPOSED STANDARD · April 1998

Phase 3 uses NHRP redirect on the hub and NHRP shortcut on spokes so hairpinned traffic triggers a direct spoke-to-spoke tunnel. Cisco IOS XE 17.x — NHRP Shortcut Switching for DMVPN §Information About Shortcut Switching

A routing protocol runs over the overlay. How next hops are advertised decides whether spokes ever try to resolve each other. Cisco — Configure BGP over DMVPN Phase 3 §DMVPN Phase 3

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

IHL 5, so no options. DF is set because the sender is doing path MTU discovery — which is why a filtered ICMP turns this into a black hole rather than a retry at a smaller size.

Link layer
Ethernet with EtherType 0x0800, or whatever the medium uses to say "IPv4 follows". RFC 791
IPv4 header
Version, length, differentiated services, fragmentation control, TTL, protocol, addresses. RFC 791
Payload
Whatever the protocol field names — 1 for ICMP, 6 for TCP, 17 for UDP, 89 for OSPF, 103 for PIM. RFC 791

Configure it

Phase 3 hub: mGRE, NHRP redirect, and tunnel protection.

Cisco IOS-XE 17.12 · ISR 4451, ASR 1000draft

  1. interface Tunnel0
 ip address 10.10.10.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile IPSEC-IKEV2

    mGRE serves every spoke on one interface. ip nhrp redirect is the Phase 3 hub half. MTU/MSS anticipate GRE+IPsec overhead on a public underlay.

    Common mistake: Configuring shortcut on the hub and redirect on the spokes — the roles are reversed.

    Cisco — Configure BGP over DMVPN Phase 3 §Hub configuration

Verify

show dmvpn
Spokes registered with NBMA addresses.
show ip nhrp
Dynamic mappings for spoke overlay addresses.

Caveats

  • IPsec profile IPSEC-IKEV2 must exist and match spoke proposals.
  • Overlay routing must not rewrite spoke next hops to the hub if Phase 3 shortcuts are required.

When it breaks

Symptom first, because that is what you have when it happens.

  1. Spokes reach the hub and cannot reach each other, on a design meant to build spoke-to-spoke tunnels.

    Narrow it down

    1. Check the phase the design is in — phase 1 has no spoke-to-spoke path by design.
    2. Confirm the hub is not setting itself as the next hop on routes it reflects.
    3. Look at whether NHRP shortcut and redirect are configured.

    Cause

    The hub is rewriting the next hop, so a spoke has no idea another spoke exists as a destination and sends everything to the hub. Direct tunnels are built from an NHRP resolution that never gets triggered.

    Fix

    Stop the hub rewriting the next hop, and enable redirect on the hub and shortcut on the spokes. Phase 3 needs all three.

    Cisco — Configure BGP over DMVPN Phase 3 §DMVPN Phase 3

  2. Tunnels come up and traffic over them is slow or fails for larger packets.

    Narrow it down

    1. Add up the overhead: GRE plus IPsec on top of the underlying MTU.
    2. Find the largest packet that crosses the tunnel with the do-not-fragment bit set.
    3. Check whether MSS clamping is configured on the tunnel interface.

    Cause

    GRE and IPsec together take a substantial bite out of the path MTU. Without clamping, the sender builds full-size segments and relies on ICMP that frequently does not survive the internet path underneath.

    Fix

    Set the tunnel MTU and clamp the MSS. On a DMVPN over the public internet this is configuration, not tuning.

    Internet Header FormatRFC 791 · INTERNET STANDARD · September 1981

  3. A spoke behind NAT cannot establish spoke-to-spoke tunnels, though it reaches the hub.

    Narrow it down

    1. Check what address NHRP registered for that spoke.
    2. Confirm whether the NAT is address-dependent.
    3. Look at whether IPsec NAT traversal is in use.

    Cause

    The spoke registered its private address, or a mapping that only works toward the hub. Another spoke resolving it gets an address it cannot reach.

    Fix

    Ensure NAT traversal is working and the registered address is the one other spokes can reach. A NAT that allocates a different mapping per destination cannot support spoke-to-spoke at all.

    Protocol OverviewRFC 2332 · PROPOSED STANDARD · April 1998

  4. Spokes fail to register and the hub NHRP cache stays empty.

    Narrow it down

    1. Compare NHRP authentication strings and network-ids on hub and spokes.
    2. Confirm the spoke’s static map to the hub NBMA address.
    3. Verify underlay reachability to the hub before blaming NHRP.

    Cause

    NHRP network-id or authentication mismatch, or a wrong hub map, prevents registration. Without registration the hub cannot resolve spokes.

    Fix

    Align network-id and authentication, fix the hub map/NHS, then confirm registration with show ip nhrp / show dmvpn.

    Cisco IOS XE 17.x — Dynamic Multipoint VPN §Configuring the Spoke for DMVPN

  5. NHRP looks correct and GRE counters move, but payload never decrypts.

    Narrow it down

    1. Check whether an IPsec profile is bound to the tunnel.
    2. Compare transform sets and IKEv2 proposals on hub and spoke.
    3. Look for traffic selectors that miss the GRE or overlay addresses.

    Cause

    IPsec is a separate SA from NHRP. A profile mismatch or missing tunnel protection leaves cleartext GRE or drops encrypted traffic while the NHRP cache still looks healthy.

    Fix

    Bring the IPsec profile up independently, then re-check NHRP and overlay routing.

    Cisco IOS XE 17.x — Dynamic Multipoint VPN §How to Configure Dynamic Multipoint VPN

Design notes

Clamp MSS and set tunnel MTU. GRE plus IPsec shrinks the usable path; ICMP for PMTUD often dies on the public underlay.

Data can bypass the hub while control cannot. A hub outage keeps existing shortcuts alive and prevents new ones.

Spoke-behind-NAT designs need correct NBMA registration and IPsec NAT traversal. Address-dependent NAT can allow hub reachability while breaking spoke-to-spoke.

Misconceptions

“DMVPN is a protocol.”
It is a design combining multipoint GRE, NHRP for resolving tunnel endpoints, a routing protocol over the tunnels, and usually IPsec. Each part is separately configurable and separately breakable, which is why "DMVPN is down" is never a diagnosis.
“Spoke-to-spoke tunnels are permanent.”
They are built on demand when traffic needs them and torn down when it stops. A spoke-to-spoke path that exists during a test and not an hour later is working as designed. IntroductionRFC 2332 · PROPOSED STANDARD · April 1998
“The hub is bypassed once spokes talk directly.”
Data bypasses it; control does not. The hub carries the routing protocol and NHRP registrations, so losing it means no new spoke-to-spoke tunnels can be built even though existing ones keep working. Cisco IOS XE 17.x — NHRP Shortcut Switching for DMVPN §Information About Shortcut Switching

More walkthroughs

Phase 3 spoke-to-spoke shortcutdesign-choice

Spoke-to-spoke traffic first hairpins the hub. With ip nhrp redirect on the hub and ip nhrp shortcut on spokes, NHRP installs an on-demand direct tunnel — then tears it down when idle.

Spoke1Spoke2Hub · redirectPath: hairpinShortcut pathvia hub
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
Spoke1router—
Spoke2router—
Hub · redirectrouterPath: hairpin
Shortcut pathlabel—
Spoke1 — Hub · redirectlinkup
Spoke2 — Hub · redirectlinkup
Spoke1 — Spoke2linkdown
1 / 3

Spoke1 sends toward a prefix behind Spoke2. The routing table still points at the hub, so the first packets hairpin. That is expected before the shortcut exists.

What changed

  • Emphasis: via hub
  • Emphasis on Spoke2 ↔ Hub · redirect
  • Hub · redirect: Path → hairpin

Hub next-hop rewrite blocks Phase 3failure

Spokes reach the hub and never each other. The hub rewrites BGP (or IGP) next hops to itself, so a spoke never treats another spoke as a destination and never triggers the NHRP resolution that would build a shortcut.

Spoke1Route to Spoke2: NH = hubSpoke2Hub · next-hop-self
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
Spoke1routerRoute to Spoke2: NH = hub
Spoke2router—
Hub · next-hop-selfrouter—
Spoke1 — Hub · next-hop-selflinkup
Spoke2 — Hub · next-hop-selflinkup
1 / 3

Both spokes register and exchange routes via the hub. Traceroutes to the hub succeed. Spoke-to-spoke prefixes exist in the table — all with the hub as next hop.

What changed

  • Spoke1: Route to Spoke2 → NH = hub
  • Emphasis on Spoke1 ↔ Hub · next-hop-self

Terms

NHRP
Next Hop Resolution Protocol: resolves an NBMA underlay address for an overlay next hop. In DMVPN, spokes register with a hub (NHS) and may resolve other spokes for Phase 3 shortcuts.
mGRE
Multipoint Generic Routing Encapsulation: one tunnel interface that can have many remote endpoints. DMVPN hubs use it so every spoke shares a single hub tunnel.

Check yourself

  • Spokes reach the hub and not each other. What is the most likely cause?
  • A spoke-to-spoke tunnel exists during a test and not an hour later. Is that a fault?
  • Why is MSS clamping standard on a DMVPN tunnel?
  • What happens to existing spoke-to-spoke tunnels if the hub fails?
  • What is DMVPN?
  • Which pair enables Phase 3 shortcuts?
  • In the underlay IPv4 header, which Protocol value indicates GRE?
  • A NAT spoke reaches the hub but not other spokes. What should you suspect?