Deploy DMVPN Phase 3 with dual-hub redundancy, IKEv2 encryption, spoke-to-spoke shortcuts, and per-tunnel QoS.
show ip nhrpshow ip nhrp shortcutshow crypto ikev2 sashow eigrp address-family ipv4 neighborsshow policy-map interface tunnel0show ip nhrp detailDMVPN Phase 3 uses NHRP 'redirect' on hubs and 'shortcut' on spokes. When spoke A sends traffic to spoke B via hub, the hub sends an NHRP redirect back to spoke A. Spoke A then sends an NHRP resolution request to learn spoke B's NBMA (public) address and builds a direct spoke-to-spoke tunnel — bypassing the hub for subsequent traffic.
Dual-hub NHS (Next Hop Server) provides redundancy: spokes register with both hubs and use one as primary, the other as fallback. EIGRP over DMVPN requires 'no split-horizon' on hub tunnel interfaces so routes learned from one spoke are re-advertised to other spokes. Without this, spoke-to-spoke routing fails.
Per-tunnel QoS (§3.2.a.iii) applies a QoS policy to each individual spoke tunnel rather than the hub physical interface. This enables per-spoke bandwidth shaping and prioritization — critical in hub-and-spoke WAN where spokes have varying link speeds. Configure 'service-policy output' on the tunnel interface.
Check NHRP network-id matches on hub and spoke. Verify authentication string matches exactly. Check underlay routing — spoke must have route to hub's physical IP (NBMA address).
Check proposal parameters match (encryption, integrity, DH group). Verify PSK matches. Use 'debug crypto ikev2' to see negotiation. Check ACL not blocking UDP 500/4500.
Add 'no ip split-horizon eigrp 100' under hub tunnel interface. Without this, hub will not re-advertise routes learned from spoke A back to spoke B.
Attempt the tasks yourself before viewing solutions.
Type SOLUTION to unlock.
HUB-WC-1
! See solution-configs/HUB-WC-1.cfg
Research and direction by Ioannis (John) Konstas; compiled and finalized with AI assistance.