Hierarchical DMVPN: One Cloud per Tunnel Relationship

A branch spoke registers successfully with its regional hub and still cannot reach a service in another region. The tunnel is up, the NHS state looks healthy, and the failure appears only for destinations that cross a tier boundary. That pattern usually means the design never stated which devices participate in which DMVPN cloud, so the tiers were built by intuition and now disagree.

The symptom appears at the tier boundary

In a hierarchical design, a central hub, several regional hubs and many branch spokes each hold a position. A regional hub can own more than one tunnel relationship, and branches do not need to register with every central endpoint. The paths that matter are branch to regional service, branch to another approved regional spoke, and branch to a central destination.

When one of those paths fails while the others work, the problem is almost always a missing or conflicting role definition rather than a broken tunnel. Write the intended paths down and compare them with what the devices actually built. That comparison takes an hour and prevents a week of guessing. Keep it with the design document.

One cloud, one interface contract

For each cloud, record the tunnel interface, the overlay addressing, the local underlay source, the NHS and NBMA relationships, multicast delivery and the protection policy. Also state which routes cross between the regional and central contexts, because that sentence is the design.

A regional hub with two tunnel interfaces needs two contracts, not one with two addresses. The underlay source, the NHRP domain and the routes can differ per interface, and a document that merges them will mislead whoever configures the second one.

Identifiers are local context, not access control

NHRP network IDs and GRE keys are the two values most often mistaken for global settings. The IOS XE NHRP guide describes the network ID as locally significant, so matching numbers on remote routers do not authenticate anything and changing one router local number does not create an access boundary.

A GRE key, where the design uses one, helps identify the receiving tunnel context, and it is agreed among the endpoints that share that context. It is not a password, and it does not replace IKE authentication or routing policy. Treat both values as configuration context that must match within a relationship, not as security controls that separate regions.

Route between tiers deliberately

Decide which prefixes the regional hub advertises upward and which central destinations it offers to its spokes. Then check the actual next hop and the phase-specific shortcut behavior for each path, because a summary route and a shortcut can produce very different forwarding than the diagram suggests.

Use routing and access policy to enforce regional separation. If a branch must not reach another region directly, the route and the policy should say so, rather than relying on an identifier that was never designed to enforce it. Write the policy down next to the identifier. Otherwise the next engineer will assume the number does the work.

Diagnose the unexpected shortcut

When a branch tries to create a direct relationship with a central endpoint, inspect its route, its NHRP mapping and the selected tunnel context before changing identifiers at random. Missing reachability, an unintended NHS relationship and a legitimate but unauthorized shortcut call for three different corrections.

The DMVPN configuration guide shows the tunnel and NHRP settings together, which is exactly why the scopes need to be separated on paper first. Record the cloud contracts, keep the tier routes explicit, and the next boundary failure will have a place to point at.