DMVPN Phase 3: NHRP Shortcut and Hub Configuration

Phase 1 forced all spoke-to-spoke traffic through the hub. Phase 2 fixed that by letting the hub advertise next-hop-self so spokes build direct tunnels, at the cost of full routing tables and per-prefix NHRP entries. Phase 3 keeps the hub as the routing summarisation point while still allowing on-demand spoke-to-spoke paths, which is why it is the deployment most enterprises actually want. Here is how it works and how to verify it.

The three phases in one table

• Phase 1 — hub-and-spoke only. Spokes point a default route at the hub; all inter-spoke traffic hairpins.
• Phase 2 — hub advertises next-hop-self, so spokes resolve each other’s NBMA addresses and build direct tunnels. Requires consistent routing at every spoke, and summarisation is difficult because each spoke must know the specific prefixes behind the others.
• Phase 3 — hub keeps its own next hop and installs NHRP shortcuts (“NHRP redirect”), so spokes can build direct paths on demand while the hub can still summarise routes.

How phase 3 actually works on the control plane

Phase 3 introduces two statements that only work as a pair: ip nhrp redirect on the hub and ip nhrp shortcut on the spokes. Almost every “phase 3 is not working” ticket ends up being one half of that pair missing. The packet flow itself is worth understanding step by step:

1. Spoke A sends a packet for 192.168.2.10, which sits behind Spoke B. Spoke A has no specific route for it, so the packet follows the summary or default route it learned from the hub and enters the mGRE tunnel.
2. The hub receives the packet on Tunnel0, looks up 192.168.2.10 in its routing table, and sees the next hop is Spoke B’s tunnel address, reachable over the very same mGRE interface the packet arrived on.
3. Because ip nhrp redirect is configured, the hub does not silently forward the packet down the same tunnel. It forwards this first packet (so the flow is not broken) and simultaneously sends an NHRP redirect message back to Spoke A, telling it that a better path to that destination exists at Spoke B’s NBMA address.
4. Spoke A reacts by sending an NHRP resolution request for Spoke B’s tunnel IP address, sourced from its own tunnel address.
5. Spoke B answers with its NBMA address, and Spoke A installs an NHRP shortcut: a /32 route towards the destination pointing directly at Spoke B, plus a cache entry mapping tunnel IP to NBMA IP.
6. Subsequent packets in both directions travel directly between the two spoke public addresses, encapsulated in a normal point-to-point IPsec tunnel, without the hub ever seeing them.

Note what does not change: every spoke still holds a summary or default route pointing at the hub, and the hub still owns the summarised prefixes. The /32 shortcut is simply more specific, so it wins while it lives in the NHRP cache. That is exactly why phase 3 scales — the hub carries one summary per region, and each spoke carries a summary plus a small number of host shortcuts that age out on their own.

Shortcut entries are tied to the NHRP cache holdtime. When the entry expires, traffic reverts to the hub path and is re-shortcut the next time the hub sends a redirect. There is nothing to clean up manually.

Hub configuration

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 ip nhrp network-id 1
 ip nhrp map multicast dynamic
 ip nhrp redirect                       ! phase 3 trigger
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-PROFILE

# Hub routes are summarised towards the spokes
router eigrp 100
 network 10.0.0.0 0.0.0.255
 network 192.168.0.0 0.0.255.255

Two details in that snippet carry most of the weight. ip nhrp map multicast dynamic lets the spokes register themselves without static map entries, and tunnel key 100 silently rejects GRE packets from any peer that does not match the key, which prevents accidental cross-talk between two DMVPN clouds that happen to share an mGRE address space. The IPsec profile referenced by tunnel protection is a standard IKEv2 profile plus transform set:

crypto ikev2 keyring DMVPN-KR
 peer SPOKES
  address 0.0.0.0 0.0.0.0
  pre-shared-key local Cisco123
  pre-shared-key remote Cisco123

crypto ikev2 profile DMVPN-IKEV2
 match identity remote address 0.0.0.0 255.255.255.255
 identity local address 203.0.113.1
 authentication remote pre-share
 authentication local pre-share
 keyring local DMVPN-KR

crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport

crypto ipsec profile DMVPN-PROFILE
 set transform-set TS
 set ikev2-profile DMVPN-IKEV2

Transport mode is the right choice for mGRE: the GRE header already provides the outer IP header that tunnel mode would duplicate, so transport mode saves 20 bytes per packet and reduces the chance of an MTU surprise.

Spoke configuration

interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1 nbma 203.0.113.1 multicast
 ip nhrp shortcut                       ! phase 3: install shortcuts from redirects
 ip nhrp map 10.0.0.1 203.0.113.1
 ip nhrp map multicast 203.0.113.1
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN-PROFILE

The profile itself is the usual IKEv2/IPsec combination, applied through tunnel protection so that the mGRE interface is encrypted transparently and NHRP traffic is protected too. The spoke also needs its own IKEv2 profile with match identity remote address 203.0.113.1 and, on the hub, match identity remote address 0.0.0.0 to accept any spoke address. That wildcard on the hub is what allows a spoke behind NAT to come up without a per-site keyring entry.

Routing and summarisation design for phase 3

Phase 3 only pays off if the routing design is deliberate. The rules that matter:

• The hub must advertise one summary per region, not per-prefix routes. With EIGRP, use ip summary-address eigrp 100 192.168.0.0 255.255.0.0 on the hub tunnel interface. With OSPF, use area 0 range on the ABR. With BGP, use aggregation.
• The spokes must not advertise their site prefixes into the tunnel in a way that leaks specifics to the hub. If a spoke sends its own /24 to the hub, the hub’s summary still exists but the hub now also holds a specific route, and it will forward inter-spoke traffic hop by hop instead of sending a redirect. Suppress spoke specifics with an outbound distribute-list or route-map on the spoke tunnel interface.
• Do not use no ip split-horizon gymnastics to force phase 2 behaviour. If you want phase 2, configure phase 2. Mixing the two produces the classic symptom where shortcuts form but traffic still flows through the hub.

BGP is generally the more predictable choice at scale. Each spoke peers with the hub, the hub originates the summary with aggregate-address ... summary-only, and the spoke’s default or summary route to the hub is injected statically. Because the shortcut is a /32 in the RIB, a BGP summary at the hub plus a static default at the spoke is enough — no summary leaking between spokes is required.

Dual hub and redundancy

Phase 3 with a single hub is a single point of failure in both the data and the control plane. Add a second hub in the same NHRP network-id. Each spoke gets two ip nhrp nhs lines; with EIGRP, pin the tunnel delay so that exactly one hub is preferred for anycast-style summarisation, or run two regions and accept active/active hierarchy. The important consequence for phase 3 is that shortcut traffic between two spokes in different regions still traverses a hub, because the NHRP redirect only fires when the hub forwards the packet out of the same mGRE interface it arrived on.

NAT, firewall and registration behaviour

Spokes behind NAT are the most common source of phase 3 failures. NAT rewrites the source UDP port during IKE, and the hub must be able to send NHRP redirects back to that translated address. Keep NAT-T enabled on both sides, and verify with show crypto session detail that the remote port is non-500 and that both sides agree. If a spoke sits behind a firewall that permits the hub but not arbitrary spoke-to-spoke traffic, phase 3 shortcuts will appear to form in the NHRP cache while the data path silently fails. Either permit spoke-to-spoke UDP 4500 across the estate or monitor and accept hub transit for those sites — but decide deliberately, because the failure looks like random application timeouts rather than a clean outage.

Scaling and performance considerations

• NHRP cache size. A hub with 500 spokes can accumulate thousands of shortcut entries under heavy any-to-any traffic. Watch show ip nhrp summary and the control-plane memory on the hub.
• Shortcut churn. Application patterns that touch many remote prefixes briefly (backup jobs crossing every site) create and expire shortcuts constantly. There is no harm in that, but it does consume hub CPU because the hub must evaluate a redirect for each new flow.
• Hub bandwidth. Even in phase 3, all initial flows transit the hub. Size the hub for the first-packet rate, not the steady-state rate.
• MTU. mGRE plus IPsec overhead is the classic silent killer. Set ip mtu 1400 and ip tcp adjust-mss 1360 on the tunnel and stop troubleshooting “random” hangs on large transfers. See our notes on TCP MSS clamping and PMTUD and on tunnelling MTU overhead for the arithmetic.

Security hardening

An mGRE interface behaves like a broadcast medium: any device that can spoof the tunnel source and knows the network-id can attempt to register. Tighten it with the following, all of which are cheap and none of which break shortcut formation:

interface Tunnel0
 ip nhrp authentication DMVPNKEY
 ip nhrp holdtime 600
 no ip split-horizon eigrp 100   ! only where EIGRP needs it, on the hub

• ip nhrp authentication protects registration and resolution messages with a plaintext secret — weak on its own, but it stops casual spoofing of the hub role.
• Because all NHRP and data traffic rides inside tunnel protection, the real protection is IKEv2 authentication. Prefer certificates over a shared pre-shared key on large deployments, and use per-spoke keys where the platform allows it.
• Bind the hub’s IKEv2 profile with match identity remote against the spoke’s certificate subject or its NBMA address rather than accepting 0.0.0.0 forever.

Verifying a shortcut actually forms

show dmvpn
show dmvpn detail
show ip nhrp
show ip nhrp shortcut
show ip route 192.168.2.0
show crypto ipsec sa | include peer

1. Ping from spoke A to a prefix behind spoke B — the first packet goes through the hub.
2. The hub sends an NHRP redirect to both spokes; each installs a shortcut entry — check show ip nhrp shortcut.
3. A second ping should now show a direct IPsec SA between the two spoke public addresses in show crypto ipsec sa.
4. show dmvpn should show the remote spoke as a dynamically learned NBMA peer, state UP, with the tunnel mode “dynamic” on peers that came up through shortcuts.

If the shortcut forms and then disappears within a minute, check for two hubs fighting over the registration: a spoke that re-registers against hub B while holding a shortcut learned through hub A will invalidate the entry, and the churn shows up as repeated NHRP registration events in debug nhrp packet.

The failure modes worth knowing

• Shortcuts never form: ip nhrp redirect missing on the hub or ip nhrp shortcut missing on the spokes. Both are required.
• One-way traffic or asymmetric routing: the hub is advertising a summary but the spokes still hold a host route via the tunnel IP — conflicting routing causes traffic to bounce.
• Spoke behind NAT: NHRP resolution needs consistent NBMA addresses and often ip nhrp map entries with NAT-T; without them the shortcut is built to an unreachable address.
• MTU: mGRE plus IPsec overhead is the classic silent killer, as noted above.
• Redirect suppressed by ACL or QoS: an inbound ACL on the tunnel that drops NHRP (protocol 17, port 4500) or a control-plane policy that rate-limits NHRP will stop redirects without any visible data-path error.
• Wrong network-id or key: spokes register against a hub with a mismatched ip nhrp network-id and the tunnel never leaves the NHRP state, yet the GRE interface stays up — a genuinely confusing combination.

Deployment checklist

• One ip nhrp network-id and one tunnel key per cloud, documented and never reused.
• ip nhrp redirect on every hub, ip nhrp shortcut on every spoke.
• Hub advertises summaries only; spokes suppress their own site specifics.
• MTU and MSS clamped on the tunnel interface before the first production flow.
• NHRP authentication enabled, IKEv2 identity restricted.
• Monitoring on NHRP cache size, shortcut count and hub CPU, with an alert when shortcut creation rate spikes.

Related reading: Cisco GRE tunnel configuration, IKEv2 SA initiation troubleshooting, EIGRP network statements and neighbour verification and TCP MSS clamping and PMTUD.

原文链接：https://www.cisco.com/c/en/us/support/docs/security/dynamic-multipoint-vpn-dmvpn/211292-Configure-Phase-3-Hierarchical-DMVPN-wit.html