Courseiva
hardMultiple ChoiceObjective-mapped

DMVPN VRF-Lite Spoke-to-Spoke Troubleshooting

A DMVPN Phase 2 network is configured with VRF-Lite. Spokes can communicate with the hub, but spoke-to-spoke traffic is not working. The engineer verifies that NHRP registrations are successful and that the spoke routers have the correct NHRP mappings for other spokes. Which is the most likely explanation?

Quick Answer

The answer is that the hub router has 'next-hop-self' configured under BGP, which causes spokes to send traffic to the hub instead of directly to the destination spoke. In a DMVPN Phase 2 network with VRF-Lite, spoke-to-spoke traffic relies on NHRP to dynamically build direct tunnels, but the spoke routers must also have a route pointing to the remote spoke’s subnet with the next-hop set to that spoke’s tunnel IP. When the hub applies 'next-hop-self' in BGP, it overwrites the original next-hop with its own tunnel address, so spokes forward inter-spoke traffic through the hub rather than using the direct spoke-to-spoke tunnel. On the Cisco CCNP ENARSI 300-410 exam, this scenario tests your understanding of how BGP next-hop processing interacts with DMVPN Phase 2’s spoke-to-spoke design—a common trap is assuming NHRP registrations alone guarantee direct traffic flow. Remember: if DMVPN VRF-Lite spoke-to-spoke is not working despite correct NHRP mappings, check BGP for 'next-hop-self' on the hub; the mnemonic “NHRP builds the tunnel, but BGP points the way” can help you recall that routing must preserve the spoke’s next-hop.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

The hub router has 'next-hop-self' configured under BGP, causing spokes to send traffic to the hub instead of directly to the destination spoke.

In DMVPN Phase 2, spoke-to-spoke tunnels are created dynamically using NHRP. However, for spoke-to-spoke traffic to work, the spoke routers must have a route to the destination subnet via the tunnel interface. Additionally, the next-hop for the spoke-to-spoke route must be the spoke router's tunnel IP, not the hub. If the hub is configured with 'next-hop-self' under BGP or if the IGP is not propagating the correct next-hop, spoke-to-spoke traffic may be forwarded through the hub instead of directly.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • The hub router has 'next-hop-self' configured under BGP, causing spokes to send traffic to the hub instead of directly to the destination spoke.

    Why this is correct

    In Phase 2, spokes need to know the next-hop is the remote spoke's tunnel IP. 'next-hop-self' on the hub overrides this, forcing traffic through the hub.

  • The NHRP authentication is mismatched between spokes, preventing the establishment of spoke-to-spoke tunnels.

    Why it's wrong here

    NHRP authentication mismatch would prevent NHRP registrations and mappings, but the problem states registrations are successful.

  • The spoke routers have a lower MTU on the physical interface, causing fragmentation issues for the GRE/IPsec packets.

    Why it's wrong here

    MTU issues can cause packet drops, but they would affect all traffic, not just spoke-to-spoke.

  • The DMVPN phase is actually Phase 3, which requires additional configuration for spoke-to-spoke traffic.

    Why it's wrong here

    Phase 3 also supports spoke-to-spoke traffic, but the configuration is different. The question states Phase 2.

Visual reference

192.168.1.0 /24 256 addresses (254 usable) 192.168.1.0 /25 Subnet A 128 addr (126 usable) 192.168.1.128 /25 Subnet B 128 addr (126 usable) Borrowing 1 bit from host portion creates 2 subnets (/25)

Go deeper

Related to this question

About these practice questions

This 300-410 question is part of Courseiva's 1,966-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on 300-410

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. In a DMVPN network with VRF-Lite, Router R1 (hub) and R2 (spoke) are configured for VRF-A. The DMVPN tunnel is up, but spoke-to-spoke traffic between R2 and R3 (another spoke) fails. R1 has configuration: interface Tunnel0, ip vrf forwarding VRF-A, ip address 172.16.0.1 255.255.255.0, tunnel source Gig0/0, tunnel mode gre multipoint. R2 has similar configuration with tunnel destination dynamic. The NHRP map for R3 is missing on R2. What is the root cause?

hard
  • A.The NHRP mapping for R3 is missing on R2, preventing direct spoke-to-spoke tunnel establishment.
  • B.The tunnel mode should be gre multipoint on all spokes.
  • C.The VRF must be removed from the tunnel interface for DMVPN to work.
  • D.The hub router must have a static route for each spoke.

Why A: In DMVPN, spoke-to-spoke tunnels require NHRP resolution. If R2 does not have an NHRP map for R3, it cannot establish a direct tunnel. The hub (R1) should facilitate NHRP resolution, but if the VRF configuration is not properly propagated, NHRP may fail. The root cause is that the NHRP mapping is missing, often due to VRF mismatch in NHRP configuration or because the hub is not properly forwarding NHRP requests.

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This 300-410 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 300-410 exam.