DMVPN Route Summary vs NHRP Summary Map: Different Tables

Someone asks you to summarize the spokes, and the ticket closes with fewer prefixes on the hub. A week later the branch-to-branch traffic that used to go direct is flowing through the hub again, and nobody connects the two changes. The phrase summarize the spokes covers two different operations that touch two different tables. Name which state you are reducing before you borrow a command from another DMVPN example.

The symptom: direct spoke traffic moved back to the hub

The distinction matters most when a Phase 2 discussion gets applied to a Phase 3 design. The same words appear in both conversations, and the effect on forwarding is not the same.

That is also why the change looked correct when it was reviewed: the review checked the routing table, which is only one of the three states involved.

One aggregation, two tables

The two operations look like this:

A routing summary is a statement about what the hub advertises and what the receiving spoke installs as a route. An NHRP summary map is a statement about the reply a spoke sends when another spoke asks how to reach an address. Those are different questions with different failure modes, and a design can change one while leaving the other exactly as it was. Treating them as one knob is how an aggregation change quietly becomes a forwarding change.

Neither operation is a statement about the protection path, which is negotiated for the peer you actually resolved.

What the hub's summary actually changes

Cisco's spoke-to-spoke NHRP summary-map guide describes a Phase 3 arrangement where the hub advertises a summary and remains the routing next hop. A redirect and a subsequent NHRP resolution then provide a more direct forwarding path. Reading only the aggregate route therefore does not describe all the forwarding state, and it does not mean every packet must traverse the hub forever. The summary is about reachability, not about the path.

That is why a design review that stops at the routing table can approve a change that alters resolution behaviour. Inspect the selected route, the NHRP result and the protection path as three separate observations.

If you cannot say which of the three changed, you have not finished the change.

What the NHRP summary map changes

Take a spoke that owns 10.32.0.0/19 through several more-specific LAN routes, while the hub advertises a larger aggregate to the other spokes. A request for 10.32.12.10 would otherwise receive resolution information for the matching smaller network. The documented NHRP summary-map feature lets the spoke return its configured covering prefix instead, which can reduce repeated resolution work for networks that belong to that spoke. It does not make the hub's routing summary and the spoke's resolution summary the same object.

Give that covering prefix a deliberate ownership model. A broad reply that includes addresses belonging elsewhere, or gaps that are unreachable, can send subsequent traffic toward an unsuitable peer.

Check the actual routes and the intended denied cases before you enlarge the prefix, not after.

Compare the first destination and one inside the summary

Pick two destinations: the first one you tested, and another that sits inside the proposed summary. For each, record the route that was selected, the NHRP state used to reach it, and the real reply path. That comparison tells you whether you changed routing scale, resolution scale, or a forwarding error, which is the only useful conclusion. A display with fewer prefixes is not evidence of any of those.

Confirm the deployed phase and the routing protocol's next-hop behaviour before you apply a Phase 3 example to your network. A short example is not proof that another design preserves the same direct-spoke path.

The ticket should say which table you reduced and which one you left alone. Anything less will be re-diagnosed from scratch in a month.