Skip to content
AvailabilitySign inBook a DemoJoin Waitlist
All CCNP topics

2.0 VPN Technologies

DMVPN & NHRP Practice Questions

DMVPN Phase 1-3 design, NHRP resolution, and spoke-to-spoke tunnels.

One solved question, so you can see how these are marked

In a DMVPN Phase 1 design, why can a spoke never build a dynamic tunnel directly to another spoke?

Spokes run point-to-point GRE interfaces, so all spoke traffic must transit the hub's mGRE interface

Phase 1 spokes use point-to-point GRE tunnels to the hub, so the hub is always the next hop for every destination and spoke-to-spoke packets must hairpin through it.

Every question in the set below is marked like this. The answers stay hidden until you pick one.

All 19 DMVPN & NHRP questions in this set

Answers and explanations appear when you work through the set above.

  1. What tunnel interface type does a Phase 2 or Phase 3 DMVPN hub require in order to support many spokes off a single interface?

    • A GRE point-to-point tunnel
    • A multipoint GRE (mGRE) tunnel
    • A loopback-sourced IPsec profile
    • A VTI bound to a static peer

  2. Which statement correctly distinguishes DMVPN Phase 2 from Phase 3 spoke-to-spoke behavior?

    • Phase 2 requires each spoke to run mGRE while Phase 3 requires point-to-point GRE
    • Phase 2 relies on the routing protocol advertising the originating spoke as next hop so a spoke can resolve it via NHRP; Phase 3 uses NHRP redirect and shortcut so any next hop works
    • Phase 2 supports hub redundancy while Phase 3 does not
    • Phase 3 cannot summarize routes at the hub, but Phase 2 can

  3. On a DMVPN hub, which NHRP command triggers the Phase 3 behavior of sending a redirect message back toward the source spoke when it hairpins traffic destined for another spoke?

    • ip nhrp shortcut
    • ip nhrp map multicast dynamic
    • ip nhrp redirect
    • ip nhrp network-id

  4. Which command is required on DMVPN spokes so they can act on redirect messages and build a shortcut route instead of continuing to send traffic through the hub?

    • ip nhrp shortcut
    • ip nhrp redirect
    • ip nhrp server-only
    • ip nhrp map multicast

  5. A spoke tunnel interface is configured with ip nhrp network-id 1 while the hub uses ip nhrp network-id 100. What is the practical effect?

    • The mismatch is cosmetic and has no effect since network-id is only used for logging
    • The values need not match because the NHRP network ID is locally significant and is not carried in NHRP packets, though using a consistent value simplifies operations
    • The hub will automatically renumber the spoke's network-id during registration
    • NHRP will still work, but multicast replication for the routing protocol will fail

  6. What role does a DMVPN spoke play from an NHRP perspective?

    • Next Hop Server (NHS)
    • Next Hop Client (NHC), registering its NBMA-to-tunnel mapping with the hub
    • Designated Router for the NHRP domain
    • NHRP relay agent for other spokes

  7. A spoke's NBMA (transport) address changes because its ISP reassigns a DHCP lease. Which statement about DMVPN spoke addressing is correct?

    • DMVPN requires every spoke to use a static, manually assigned NBMA address
    • A spoke's NBMA address can be dynamically obtained, for example via DHCP, since only the hub's NBMA address needs to be known in advance for initial registration
    • Changing the NBMA address always requires reconfiguring the tunnel-id on all spokes
    • Only the hub is permitted to use a dynamically assigned NBMA address

  8. A newly built DMVPN spoke can ping the hub's NBMA address across the underlay, but show dmvpn shows no NHRP entry for the spoke and the tunnel never comes up. What should be checked first?

    • The BGP AS number configured on the hub
    • Underlay/transport routing has already been confirmed working, so the next step is NHRP registration parameters: matching network-id, correct NHS statement pointing at the hub tunnel IP, and any NHRP authentication string mismatch
    • The OSPF process ID configured on the spoke
    • Whether the hub's loopback interface has an IP address

  9. Why is it considered a design mistake to let a spoke learn a route to the hub's NBMA (transport) address across the DMVPN tunnel itself?

    • It has no real effect since GRE ignores routing table entries
    • It creates recursive routing: the router tries to reach the tunnel destination through the tunnel that depends on reaching that same destination, which destabilizes or drops the tunnel
    • It causes NHRP to disable multicast mapping
    • It forces the tunnel into Phase 1 behavior

  10. Which command displays a concise summary of a router's active DMVPN peers, their NBMA/tunnel address mappings, and tunnel state?

    • show ip nhrp brief
    • show dmvpn
    • show crypto isakmp sa
    • show ip route nhrp

  11. On a hub with several protected DMVPN tunnels sourced from the same physical interface using the shared keyword, why does each tunnel interface need a unique tunnel key?

    • Tunnel keys negotiate the IKEv2 proposal used for that tunnel
    • The shared IPsec SADB uses the tunnel key to demultiplex decrypted traffic back to the correct GRE tunnel interface when multiple tunnels share one source and destination pair
    • Tunnel keys are required only when using GRE without IPsec protection
    • Tunnel keys replace the need for an NHRP network-id

  12. Which two protocols/headers typically add overhead to DMVPN traffic and are the reason tunnel IP MTU is commonly lowered below 1500 bytes?

    • OSPF and EIGRP header overhead only
    • GRE encapsulation, and IPsec/ESP encapsulation when the tunnel is protected
    • NHRP and BGP header overhead only
    • 802.1Q tagging and MPLS label imposition

  13. What does ip tcp adjust-mss accomplish when applied to a DMVPN tunnel interface?

    • It rewrites the TCP MSS value in the SYN/SYN-ACK exchange so end hosts negotiate a segment size that fits after GRE/IPsec overhead, avoiding path-MTU-related fragmentation or black-holing
    • It changes the IP MTU advertised in OSPF hello packets
    • It forces all TCP sessions to use jumbo frames
    • It disables PMTUD for UDP-based applications

  14. Best practice discourages running DMVPN Phase 1 and Phase 3 spokes on the same tunnel interface and subnet. What is the recommended way to migrate a subset of spokes to a higher phase without a flag day?

    • Enable ip nhrp shortcut on Phase 1 spokes only, leaving the rest unchanged
    • Stand up a separate DMVPN tunnel network (different subnet, new tunnel interface, its own network-id) for the higher-phase spokes and migrate them onto it
    • Change only the hub's phase, since spokes automatically negotiate their phase with the hub
    • Disable NHRP redirect on the hub until every spoke has been upgraded

  15. What limitation does ip nhrp authentication actually provide on a DMVPN tunnel interface?

    • Strong, replay-protected cryptographic authentication of NHRP packets equivalent to IPsec
    • A simple plaintext-comparison check that helps prevent an obviously unrelated NHRP/DMVPN domain from accidentally forming an adjacency; it is not a substitute for IPsec protection
    • Mutual RSA certificate authentication between hub and spokes
    • Per-spoke unique keys automatically rotated every registration interval

  16. A hub uses ip nhrp map multicast dynamic on its tunnel interface. What does this accomplish for a routing protocol running over the mGRE tunnel?

    • It statically defines every spoke's NBMA address ahead of time
    • It tells the hub to automatically replicate multicast/broadcast traffic, such as OSPF hellos or EIGRP hellos, to every spoke that has dynamically registered, without needing a static multicast map per spoke
    • It disables multicast entirely to force unicast-only routing protocol operation
    • It configures PIM sparse mode on the tunnel interface

  17. Two spokes behind different front-door VRFs (FVRF) both terminate their DMVPN tunnel on a hub using a single global-VRF tunnel interface. What is the purpose of the FVRF on each spoke?

    • FVRF is only relevant to BGP route reflectors and has no bearing on DMVPN
    • It keeps the transport/underlay routing table used to reach the hub's NBMA address separate from the customer/overlay routing table carried inside the tunnel, which also prevents overlay routes from leaking into the underlay
    • It replaces the need for an IPsec profile on the tunnel
    • It forces the spoke into Phase 1 operation

  18. A spoke can reach the hub's NBMA address, but show dmvpn shows the tunnel state stuck at NHRP and never reaching UP with crypto engaged. Which layer should be checked next, following underlay-first troubleshooting order?

    • OSPF area configuration
    • IKEv2/IPsec negotiation, for example matching IKEv2 proposals, authentication, and whether tunnel protection ipsec profile is applied and using a valid profile
    • BGP route-reflector configuration
    • The DHCP relay agent on the spoke's LAN interface

  19. In a correctly working Phase 3 DMVPN, a spoke sends the first packet toward another spoke's LAN subnet. What is the expected initial forwarding path for that very first packet, before any shortcut is installed?

    • It is dropped until NHRP resolution completes
    • It is forwarded through the hub, since routing points to the hub as next hop until the redirect/resolution exchange completes and a direct shortcut route is installed
    • It is broadcast to every spoke simultaneously
    • It is always sent using the destination spoke's tunnel IP as the NBMA address without any NHRP lookup