按隧道 QoS 不会限制你 Hub 的总上行带宽

这种说法听起来像算术：五个 Spoke 各被塑形到 5 Mbit/s，于是 Hub 最多承载 25 Mbit/s。前半句成立，结论不成立。按隧道的策略是按每条隧道各执行一次，而不是按 Hub 执行一次，五条隧道共同穿过的共享上行链路根本不出现在这个计算里。上行链路上的拥塞照旧存在。

这种说法从何而来

混淆可以理解，因为 NHRP 组信息让一份策略定义可以作用于整组 Spoke。这在配置文件里读起来像共享预算。它实际意味着每个 Spoke 各自得到该定义的一个实例。

所以每个 Spoke 5 Mbit/s 是每条隧道的上限，上限的个数等于隧道的条数。

一份策略实例控制什么

Cisco 的 IOS XE 上 DMVPN 按隧道 QoS 指南 描述了按 NHRP 组信息选取、并对每个 Spoke 单独应用的 Hub 出向策略。这句话推出两点限制，而两点都被忽略。速率属于单个 Spoke，而不是共享桶；该特性管控的是从 Hub 到 Spoke 的流量，而非反向。

单独规划 Spoke 的发送方向。Hub 出向策略里没有任何东西限制分支上传多少。

把总量限制放在共享瓶颈上

总量必须在 它真正竞争的地方塑形：也就是所有隧道共用的物理接口。Cisco 把物理接口上的 class-default 整形器记载为该特性所支持的并发物理策略，这比你能敲出的任何层级都更窄。在有人反证之前，请假定自己发明的任意第二条物理策略不受支持。

然后决定所有 Spoke 同时忙碌时会发生什么。哪些流量被放行、哪一类获得优先、哪个队列承担竞争。按 Spoke 的上限对这些一个问题都答不上来，因为每个 Spoke 是单独考虑的。

把整形单位和开销核算对齐到实际交接。你在速率计算里漏掉的封装开销，会表现为在配置数值之前就饱和的链路。

计数器会在一个特定意义上说谎

在你正在整形的层面读计数器。同一份 Cisco 指南警告：在这种排布下主接口的策略计数器可能不准。那是对计数器的保留意见，不是某类在匹配或丢弃的证据。请把它与应用结果分开，后者才是用户唯一能感知的东西。

把旧的 traffic-shape 示例贴在一张无关的策略图旁边，并不能证明两个速率控制的是同一批报文。

测试总量，而不只是上限

先从一个忙碌的 Spoke 开始，确认它到达自己的上限。然后在一份已批准的方案下让所有 Spoke 同时产生流量，并盯住物理接口与按隧道数字的关系。如果每个 Spoke 都停在自己的上限、而上行链路打满且时延上升，那么按 Spoke 的策略完全按设计工作，而预算仍然是错的。

此时的修正是容量或准入决策。重新调整按 Spoke 的数字，只会改变哪家分支先抱怨。