Skip to content
Log in Sign up My account

2.3 DMVPN Phases, Spoke-to-Spoke and Routing

Blueprint 2.3: Configure and verify DMVPN (single hub)

  • 2.3.d Dynamic neighbor
  • 2.3.e Spoke-to-spoke
  • Phases 1, 2 and 3, and what each phase needs from the routing protocol: split horizon, next hop and summarization

The building blocks (mGRE, NHRP and IPsec) are on DMVPN Building Blocks. This page assumes that cloud is already up.

Most DMVPN exam questions are really routing questions. The tunnel is up, the spokes are registered, and yet traffic between spokes goes through the hub, or a spoke is missing routes. The answer depends on the phase, because each phase uses the routing table differently. Learn the table below until you can reproduce it from memory.

The three phases at a glance

Phase 1 Phase 2 Phase 3
Hub tunnel mGRE mGRE mGRE + ip nhrp redirect
Spoke tunnel Point-to-point GRE (tunnel destination hub) mGRE mGRE + ip nhrp shortcut
Spoke-to-spoke traffic Always through the hub Direct, after NHRP resolution First packets through the hub, then direct after redirect and resolution
What triggers resolution Nothing The routing table next hop is another spoke's tunnel address An NHRP redirect from the hub
Hub may summarize or send default Yes No Yes
Hub may set itself as next hop Yes No Yes
Scales to large clouds Yes, but no spoke-to-spoke Poorly (every spoke holds every route) Yes 
graph TB
  subgraph P1 ["Phase 1"]
    H1["Hub"] --- A1["Spoke A"]
    H1 --- B1["Spoke B"]
  end
  subgraph P2 ["Phase 2"]
    H2["Hub"] --- A2["Spoke A"]
    H2 --- B2["Spoke B"]
    A2 === B2
  end
  subgraph P3 ["Phase 3"]
    H3["Hub"] --- A3["Spoke A"]
    H3 --- B3["Spoke B"]
    A3 === B3
  end

The thick line is a dynamic spoke-to-spoke tunnel. Phase 2 and phase 3 look the same once the shortcut exists; the difference is what makes the spoke build it.

Phase 1: hub and spoke

Spokes use ordinary point-to-point GRE to the hub. They can only ever send to the hub, so there is nothing to resolve, and all spoke-to-spoke traffic is relayed by the hub.

! Phase 1 spoke
interface Tunnel0
 ip address 172.16.0.2 255.255.255.0
 ip nhrp network-id 1
 ip nhrp nhs 172.16.0.1 nbma 203.0.113.1 multicast
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.1
 tunnel key 100
 tunnel protection ipsec profile DMVPN-PROF

The spoke still registers with NHRP so the hub learns its NBMA address dynamically. The hub stays mGRE.

Routing in phase 1: the hub is the next hop for everything, so the hub can send each spoke just a default route or a summary. If the spokes must learn each other's specific routes, disable split horizon on the hub tunnel (EIGRP), or the hub never readvertises routes it learned on Tunnel0 back out of Tunnel0.

Phase 2: spoke-to-spoke driven by the routing table

Spokes use mGRE. When a spoke looks up a destination and the routing table says "next hop 172.16.0.3 via Tunnel0", it needs the NBMA address for 172.16.0.3. It has no mapping, so it sends an NHRP resolution request through the hub. The request is forwarded to the spoke that owns 172.16.0.3, which replies directly. The two spokes then build an IPsec SA and send traffic directly. Packets sent while resolution is in progress go through the hub.

That only works if the route to the remote spoke's LAN has the remote spoke's tunnel address as next hop. Everything about phase 2 routing follows from that rule:

  • The hub must not change the next hop when it readvertises spoke routes.
  • The hub must not summarize or send only a default route. A summary has the hub as next hop, so every packet goes to the hub.
  • The hub must readvertise spoke routes back out of the tunnel they came in on, so split horizon must be off where the protocol uses it.

Routing protocol settings for phase 2

interface Tunnel0
 no ip split-horizon eigrp 100
 no ip next-hop-self eigrp 100

router eigrp DMVPN
 address-family ipv4 unicast autonomous-system 100
  af-interface Tunnel0
   no split-horizon
   no next-hop-self


! Hub
interface Tunnel0
 ip ospf network broadcast
 ip ospf priority 255
! Every spoke
interface Tunnel0
 ip ospf network broadcast
 ip ospf priority 0
On a broadcast network the DR does not change the next hop in the network LSA, so spokes keep each other's tunnel addresses as next hops. The hub must be the DR, because only the hub is adjacent to every spoke. Spokes get priority 0 so a spoke can never become DR or BDR.

router bgp 65000
 neighbor SPOKES peer-group
 neighbor SPOKES remote-as 65000
 neighbor SPOKES route-reflector-client
A route reflector does not change the next hop of reflected routes, so spokes see each other's tunnel addresses. Do not add next-hop-self on the hub for phase 2.

Exam trap

OSPF point-to-multipoint works on DMVPN but breaks phase 2 spoke-to-spoke, because the hub becomes the next hop for every spoke route. Broadcast with the hub as DR keeps the original next hop. Also remember that a tunnel interface defaults to OSPF network type point-to-point, which allows only one neighbor. A hub left at the default keeps flapping between spokes.

Exam trap

In phase 2 with EIGRP, no ip split-horizon eigrp alone is not enough. Spokes then receive each other's routes, but with the hub as next hop, so traffic still hairpins. no ip next-hop-self eigrp is also needed. If the exhibit shows the remote spoke LAN via 172.16.0.1 (the hub), next-hop-self is still on.

Phase 3: spoke-to-spoke driven by NHRP

Phase 3 removes the phase 2 rule. The hub can send summaries or a default route, with itself as next hop, and spokes still build direct tunnels.

  1. Spoke A sends a packet for spoke B's LAN to the hub, because the summary route points at the hub.
  2. The hub forwards the packet to spoke B. Because the packet came in and went out on the same NHRP network (same ip nhrp network-id on the hub), the hub sends spoke A an NHRP redirect (traffic indication).
  3. Spoke A sends a resolution request for the destination. It travels through the hub to spoke B.
  4. Spoke B replies directly to spoke A with its NBMA address and the matching prefix (for example 10.3.3.0/24). Spoke B also learns spoke A's mapping.
  5. Spoke A installs a shortcut: an NHRP route in the routing table, or a next-hop override on an existing route. Later packets go directly to spoke B.
sequenceDiagram
  participant A as Spoke A
  participant H as Hub
  participant B as Spoke B
  A->>H: Data to 10.3.3.1 (via summary)
  H->>B: Data forwarded
  H-->>A: NHRP Redirect
  A->>H: Resolution Request for 10.3.3.1
  H->>B: Resolution Request forwarded
  B-->>A: Resolution Reply (10.3.3.0/24 at NBMA 198.51.100.5)
  A->>B: Data, direct spoke-to-spoke
! Hub
interface Tunnel0
 ip nhrp redirect
 ip summary-address eigrp 100 10.0.0.0 255.0.0.0
! Spokes
interface Tunnel0
 ip nhrp shortcut

How the shortcut appears in the routing table

R2# show ip route | begin Gateway
Gateway of last resort is 198.51.100.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 198.51.100.2
D     10.0.0.0/8 [90/2944000] via 172.16.0.1, 00:21:15, Tunnel0
      10.2.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        10.2.2.0/24 is directly connected, Loopback1
L        10.2.2.1/32 is directly connected, Loopback1
      10.3.0.0/24 is subnetted, 1 subnets
H        10.3.3.0 [250/1] via 172.16.0.3, 00:00:07, Tunnel0
Code Meaning
H (NHRP), AD 250 A new, more specific route installed by NHRP. It wins over the summary by longest match, not by AD.
% (next-hop override) The spoke already had a route with the same prefix through the hub. NHRP overrides its next hop instead of adding a new route. Seen with show ip route as D %.

show ip nhrp lists the shortcut entries and show dmvpn lists the spoke-to-spoke peer with attribute D (dynamic) and T1 (route installed) or T2 (next-hop override).

Exam trap

Both spokes need ip nhrp shortcut. If only spoke A has it, traffic from A to B goes direct but traffic from B to A still goes through the hub, because B ignores redirects. ip nhrp redirect is a hub command; putting it on spokes does nothing for spoke-to-spoke. A summary route on the spokes is normal in phase 3 and is not the fault.

Routing protocol checklist by phase

Setting Phase 1 Phase 2 Phase 3
EIGRP split horizon on hub Off if spokes need specific routes; otherwise hub sends summary or default Off Can stay on if the hub sends a summary or default
EIGRP next-hop-self on hub Default (on) Off Default (on)
Summarization on hub Allowed Not allowed Allowed and recommended
OSPF network type Point-to-multipoint, or broadcast with hub DR Broadcast, hub DR, spokes priority 0 Point-to-multipoint (or broadcast)
BGP Hub sends default or summary Hub is RR, next hop unchanged Hub sends default or summary with next-hop-self

Additional points that come up in exhibits:

  • OSPF timers must match. Broadcast uses 10/40 second hello and dead timers; point-to-multipoint uses 30/120. A hub on point-to-multipoint and spokes on broadcast never form adjacencies.
  • OSPF cannot summarize inside an area. With all DMVPN routers in one area, OSPF phase 3 still works through redirects, but every spoke still holds every route. That is why EIGRP and BGP are the usual DMVPN protocols.
  • EIGRP stub on spokes. eigrp stub connected on each spoke stops the hub from sending queries to spokes and stops a spoke being used as a transit path. It is good design in every phase.
  • Tunnel bandwidth. The default bandwidth of a GRE tunnel interface is low, which makes EIGRP metrics through the tunnel very large and limits EIGRP's own packets to a share of it. Set bandwidth on the tunnel.
  • No routing adjacency between spokes. Spoke-to-spoke tunnels carry data only. Spokes only map multicast to the hub, so EIGRP or OSPF hellos are never sent spoke to spoke. All routing goes through the hub.

Dynamic neighbors

A single-hub DMVPN is "dynamic" at every layer: the hub has no per-spoke configuration.

Layer How the hub learns a new spoke
NHRP The spoke's registration request creates a dynamic mapping (show ip nhrp, type dynamic)
Multicast ip nhrp map multicast dynamic adds the spoke's NBMA address to the replication list
IPsec The wildcard pre-shared key (or certificates) and the IPsec profile accept any peer
EIGRP or OSPF Multicast hellos form neighbors automatically once the spoke is in the multicast list
BGP bgp listen range accepts incoming sessions from any address in the tunnel subnet

BGP does not discover neighbors by multicast, so without dynamic neighbors the hub would need one neighbor statement per spoke. BGP dynamic neighbors let the hub accept sessions from a whole range and apply a peer group to them:

! Hub, iBGP AS 65000
router bgp 65000
 bgp router-id 172.16.0.1
 bgp listen range 172.16.0.0/24 peer-group SPOKES
 bgp listen limit 200
 neighbor SPOKES peer-group
 neighbor SPOKES remote-as 65000
 !
 address-family ipv4
  neighbor SPOKES activate
  neighbor SPOKES route-reflector-client
 exit-address-family
!
! Each spoke points at the hub as usual
router bgp 65000
 neighbor 172.16.0.1 remote-as 65000
 address-family ipv4
  network 10.2.2.0 mask 255.255.255.0

The hub is passive for dynamic peers: it never opens the session; the spoke must. The peer group must have a remote-as, which every dynamic peer inherits. bgp listen limit caps the number of dynamic peers; the default is 100.

R1# show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
*172.16.0.2     4        65000      14      16        5    0    0 00:09:12        1
*172.16.0.3     4        65000      14      16        5    0    0 00:09:08        1
* Dynamically created based on a listen range command
Dynamically created neighbors: 2, Subnet ranges: 1

Exam trap

If a BGP dynamic neighbor never comes up, check three things: the spoke's tunnel address is inside the bgp listen range, the spoke has a neighbor statement pointing at the hub (the hub will not initiate), and the AS in the peer group matches the spoke's AS. The listen range uses the tunnel subnet, not the NBMA addresses.

Troubleshooting flow

Work from the bottom up. Each layer depends on the one below.

Layer Check Typical faults
Underlay ping <hub NBMA> source <spoke NBMA interface> No route to the hub, ACL on the Internet edge blocking UDP 500/4500 or ESP
IPsec show crypto isakmp sa, show crypto ipsec sa Key mismatch, policy mismatch, transform set mismatch
GRE and NHRP show dmvpn, show ip nhrp nhs detail Tunnel key mismatch, NHRP authentication mismatch, wrong NHS or NBMA address
Multicast show ip nhrp multicast on the hub Missing ip nhrp map multicast dynamic
Routing show ip eigrp neighbors, show ip ospf neighbor, show ip bgp summary OSPF network type or timers, EIGRP AS mismatch, BGP listen range
Routes show ip route on a spoke Split horizon, next-hop-self or summarization wrong for the phase
Spoke-to-spoke show dmvpn after traffic, show ip nhrp, traceroute Missing shortcut or redirect, spoke-to-spoke IPsec blocked

Lab: walk the phases

Topology: the lab from DMVPN Building Blocks: hub R1 (Tu0 172.16.0.1), spokes R2 (172.16.0.2, LAN 10.2.2.0/24) and R3 (172.16.0.3, LAN 10.3.3.0/24), Internet R4.

graph LR
  R2["R2 SPOKE1<br/>10.2.2.0/24"] -- "Tu0" --- R1["R1 HUB<br/>10.1.1.0/24"]
  R1 -- "Tu0" --- R3["R3 SPOKE2<br/>10.3.3.0/24"]
  R2 -. "spoke-to-spoke" .- R3

Steps

  1. Phase 1. On R2 and R3, change the tunnel to point-to-point: no tunnel mode gre multipoint, tunnel destination 203.0.113.1, and remove ip nhrp shortcut. On R1 remove ip nhrp redirect. Run traceroute 10.3.3.1 source Loopback1 from R2 twice. Both go through 172.16.0.1. show dmvpn on R2 never shows R3.

  2. Phase 2. Put R2 and R3 back to tunnel mode gre multipoint (remove tunnel destination first). On R1 configure no ip split-horizon eigrp 100 and no ip next-hop-self eigrp 100. On R2 check:

    R2# show ip route 10.3.3.0
Routing entry for 10.3.3.0/24
  Known via "eigrp 100", distance 90, metric 2944000, type internal
  Routing Descriptor Blocks:
  * 172.16.0.3, from 172.16.0.1, 00:00:41 ago, via Tunnel0

    The next hop is R3's tunnel address, learned from the hub. Run the traceroute twice: the second one goes directly to 172.16.0.3. 3. Break phase 2. Add ip summary-address eigrp 100 10.0.0.0 255.0.0.0 on R1's tunnel. R2 now has only 10.0.0.0/8 via 172.16.0.1, and spoke-to-spoke traffic goes through the hub again. 4. Phase 3. Keep the summary. Add ip nhrp redirect on R1 and ip nhrp shortcut on R2 and R3. Clear NHRP on the spokes (clear ip nhrp). Traceroute from R2 twice: first through the hub, then direct. Confirm the H route with show ip route nhrp and the DT1 entry in show dmvpn on R2. 5. Dynamic neighbors with BGP. Replace EIGRP with iBGP AS 65000 using the bgp listen range configuration above on R1 and a single neighbor 172.16.0.1 on each spoke. Have the hub send only a default route to the spokes (neighbor SPOKES default-originate and an outbound prefix list that permits only 0.0.0.0/0). Confirm phase 3 shortcuts still form. 6. Break it. Remove ip nhrp shortcut from R3 only. Compare traceroutes from R2 to R3 and from R3 to R2. One is direct, one hairpins through the hub.

Quick check

A phase 2 DMVPN uses OSPF point-to-multipoint on all tunnels. Spoke-to-spoke tunnels never form. Why, and what are the two ways to fix it?

Point-to-multipoint makes the hub the next hop for every spoke route, so spokes never need to resolve each other. Change to network type broadcast with the hub as DR and spokes at priority 0 (staying in phase 2), or move to phase 3 with ip nhrp redirect on the hub and ip nhrp shortcut on the spokes.

In phase 3, the spoke's routing table shows D % 10.3.3.0/24 via 172.16.0.1. What does the % mean?

Next-hop override. The spoke already had an EIGRP route for exactly 10.3.3.0/24 through the hub, and NHRP replaced its next hop with the shortcut toward the other spoke instead of installing a separate H route.

Why does the hub not need a neighbor statement for each spoke when BGP runs over DMVPN with bgp listen range?

The hub accepts any incoming BGP session sourced from an address in the listen range and applies the peer group settings to it. The spokes initiate the sessions; the hub stays passive for dynamic peers.

References