hardMultiple Choice
350-401 Practice Question: Is configuring a DMVPN Phase 3 deployment with…
A network engineer is configuring a DMVPN Phase 3 deployment with EIGRP as the routing protocol. The hub router has multiple spoke routers behind a single physical interface. The engineer notices that spoke-to-spoke traffic is being forwarded through the hub instead of directly. The spoke routers have the correct NHRP and mGRE configuration. What is the most likely cause of this issue?
⚠ Common exam trap
Cisco often tests the distinction between Phase 2 and Phase 3 DMVPN behavior, where candidates mistakenly think 'ip next-hop-self' is always required for EIGRP over DMVPN, but in Phase 3 it must be disabled to allow NHRP shortcut resolution.
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 is configured with 'ip next-hop-self eigrp' under the tunnel interface.
In DMVPN Phase 3, spoke-to-spoke direct communication relies on the hub sending an NHRP Redirect to inform the source spoke of a better path. However, if the hub has 'ip next-hop-self eigrp' configured under the tunnel interface, EIGRP updates sent from the hub will set the next-hop to the hub's own tunnel IP address. This causes the spoke routers to install routes with the hub as the next-hop, preventing them from triggering an NHRP resolution for a direct spoke-to-spoke tunnel. The correct behavior for Phase 3 is to use 'no ip next-hop-self eigrp' so that the original spoke's next-hop is preserved, allowing spokes to resolve the destination via NHRP.
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 is configured with 'no ip next-hop-self eigrp' under the tunnel interface.
Why it's wrong here
This configuration would have the opposite effect. With 'no ip next-hop-self eigrp', EIGRP advertises routes with the original next hop (the remote spoke's tunnel IP), enabling spokes to learn each other's addresses and trigger NHRP to build direct tunnels. Therefore, this is not the cause of the problem; the problem is caused by the default or explicit 'ip next-hop-self' on the hub, which hides the remote spoke's IP.
- ✓
The hub router is configured with 'ip next-hop-self eigrp' under the tunnel interface.
Why this is correct
In a DMVPN phase 3 deployment with EIGRP, the hub's 'ip next-hop-self eigrp' overrides the next hop in advertised routes to the hub's own tunnel address. As a result, spokes receive routing updates that point to the hub for all remote networks, so they never discover the actual tunnel IP of the destination spoke. Without that real next hop, NHRP's shortcut triggering mechanism never fires, and traffic must hair-pin through the hub instead of building a direct spoke-to-spoke tunnel.
- ✗
The spoke routers have 'ip nhrp shortcut' configured but the hub does not have 'ip nhrp redirect'.
Why it's wrong here
Incorrect. NHRP redirect is used on the hub to inform spokes that a better path exists. Without it, spokes may still forward through the hub, but the primary cause here is the next-hop-self behavior in EIGRP.
- ✗
The spoke routers are using static NHRP mappings to the hub only, without dynamic NHRP registration.
Why it's wrong here
While static mappings to the hub prevent spokes from resolving each other dynamically, the scenario implies that NHRP registration and mGRE are functioning correctly. In a properly configured DMVPN, spokes register their tunnel addresses with the NHRP server (hub), and the hub retains a database of spoke addresses; static hub-only mappings alone would not prevent spokes from learning remote spokes if EIGRP advertised their real next hops. Thus this is not the root cause; the EIGRP next-hop manipulation is the decisive factor.
Visual reference
Quick reference
Routing Protocol Comparison
| Protocol | Metric | Max Hops | Algorithm | Type |
|---|---|---|---|---|
| RIP v2 | Hop count | 15 | Bellman-Ford | Distance vector |
| OSPF | Cost (bandwidth) | Unlimited | Dijkstra (SPF) | Link state |
| EIGRP | Composite metric | Unlimited | DUAL | Hybrid |
| IS-IS | Cost | Unlimited | Dijkstra | Link state |
| BGP | Policy / attributes | Unlimited | Path vector | Path vector |
RIP's 15-hop limit makes it unsuitable for large networks. OSPF and EIGRP dominate modern enterprise deployments.
Go deeper
Related to this question
About these practice questions
This 350-401 question is part of Courseiva's 1,923-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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 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 350-401 exam.