Per-Tunnel QoS Does Not Cap Your Hub's Total Uplink

The belief sounds like arithmetic: five spokes each shaped to 5 Mbit/s, so the hub carries 25 Mbit/s at most. The first half is true and the conclusion is not. A per-tunnel policy is applied once per tunnel, not once per hub, and the shared uplink that all five tunnels cross never appears in that calculation. Congestion on the uplink survives exactly as it was.

Where the belief comes from

The confusion is understandable, because NHRP group information lets one policy definition apply to a whole set of spokes. That reads like a shared budget in a configuration file. What it actually means is that each spoke gets its own instance of that definition.

So 5 Mbit/s per spoke is a per-tunnel ceiling, and there are as many ceilings as there are tunnels.

What one policy instance controls

Cisco's IOS XE per-tunnel DMVPN QoS guide describes a hub egress policy selected through NHRP group information and applied separately to each spoke. Two limits follow from that sentence, and both get ignored. The rate belongs to one spoke rather than to a shared bucket, and the feature governs traffic from the hub to the spoke, not the reverse.

Plan the spoke's sending direction independently. Nothing in a hub egress policy caps what a branch uploads.

Put the aggregate limit at the shared bottleneck

The aggregate has to be shaped where the aggregate actually competes: the physical interface all the tunnels share. Cisco documents a class-default shaper on the physical interface as the supported concurrent physical policy for this feature, which is a narrower statement than every hierarchy you can type. Assume the arbitrary second physical policy you invented is unsupported until somebody proves otherwise.

Then decide what happens when every spoke is busy at once. Which traffic is admitted, which class is prioritised, and which queue owns contention. A per-spoke ceiling answers none of those questions, because each spoke is considered alone.

Match shaping units and overhead accounting to the actual handoff. Encapsulation overhead you leave out of the rate calculation shows up as a link that saturates before the configured number.

Counters lie in one specific way

Read counters at the layer you are shaping. The same Cisco guide warns that main-interface policy counters can be inaccurate in this arrangement. That is a caveat about the counter, not evidence that a class is matching or dropping. Keep it separate from the application result, which is the only thing the user experiences.

Copying an old traffic-shape example next to an unrelated policy map does not establish that the two rates control the same packets.

Test the aggregate, not just the ceiling

Start with one busy spoke and confirm it reaches its ceiling. Then offer traffic from all of them at once under an approved plan, and watch the physical interface beside the per-tunnel numbers. If each spoke sits at its ceiling while the uplink is pinned and delay climbs, the per-spoke policy is working exactly as designed and the budget is still wrong.

The fix at that point is a capacity or admission decision. Re-tuning per-spoke numbers only changes which branch complains first.