DMVPN Phase 3: reading the shortcut in both directions

You watch one ping go spoke to spoke, it takes the long way through the hub, and the second one goes direct. It is tempting to call the shortcut working at that point. That conclusion is half right. The forward path may be shortcut while the return path still rides the hub, and the state that proves each direction is different state. Walk both directions and read three tables before you accept the design as healthy.

Start with the packet path you can actually see

Begin at a spoke with a destination that should be direct. Trace the first packet: it follows the spoke's route toward the hub, because no shortcut exists yet. The hub forwards it and, in a Phase 3 design, also sends a redirect to the source saying a better path exists.

That redirect is the trigger, not the proof. It says the hub saw traffic that could be optimized. It does not say the source built the shortcut, that the destination answered the resolution, or that the reply path uses it.

So the first useful observation is a before and after: the first flow through the hub, the later flow direct.

Three states that look like one tunnel

The shortcut depends on three pieces of state, and each has its own lifetime and its own command.

An NHRP cache entry maps an overlay address to an NBMA transport address. A route or shortcut decides how one inner destination is forwarded. An IPsec association protects whatever traffic results. A missing reply can come from any of the three, and the commands tell you which one is absent.

Read them in that order, because a missing mapping makes the other two uninteresting.

Walk the request and the reply separately

From spoke A, ask for the resolution and watch what comes back. The request goes through the supported NHRP forwarding path, and the destination can answer directly instead of through the hub. That asymmetry is normal, and it is why the reply is the interesting half of the exchange.

Now reverse the roles. Send from B to A and repeat the same three reads. A design that shortcuts one direction and not the other is not symmetric, and the asymmetry usually comes from a missing prefix on one side or a resolution that never got an answer.

The peer's reply need not traverse the hub just because the request did. Do not read that as an error and start chasing a routing fault that does not exist.

Read the hub's redirect, not just its route

The hub's route table tells you where the hub would send a packet. The redirect tells you what the hub asked the source to do about it. Those are different facts, and a hub with a correct route and no redirects will keep every flow on the long path indefinitely. Check the hub's NHRP events and confirm redirects are being generated for the traffic you care about.

Phase 3 also changes what summarization means. With shortcut behavior, spokes do not need the full set of specific remote routes a Phase 2 design expected, so a summarized route at the spoke is not automatically a missing network. Confirm the phase and the routing policy before reading a summary as a fault.

That one misunderstanding causes more DMVPN tickets than any other.

Record the conclusion as a missing object

Finish with an authorized application flow and its reply, and note for each direction whether it used the direct path. Then write the conclusion as the object that was missing: a mapping, a forwarding shortcut, a protection association, or an application response.

A routing adjacency and a shared security association are evidence of health, not evidence of the path. Both can be perfect while every packet still takes the long way around. Check the forwarding decision first, then the association that carries it. The order matters, because the association forms either way.

That habit pays off on the next ticket. Tunnel is up but slow becomes B has no shortcut for A's host, and the second statement is a five-minute fix. Keep the command output with the conclusion, and keep the vendor's Phase 3 walkthrough next to it.