DMVPN 路由汇总与 NHRP 汇总映射：两张不同的表
路由汇总改变对外通告的前缀和下一跳。NHRP 汇总映射改变解析应答返回的内容。同一个词，另一张表。
有人请你汇总 spoke，工单以 hub 上更少的前缀收尾。一周后，原本直连的分支间流量又绕回 hub，而且没有人把这两次变更联系起来。汇总 spoke 这个说法涵盖了两个触及不同表的操作。在借用另一个 DMVPN 示例里的命令之前，先说清你在削减哪一种状态。
症状：直连的 spoke 流量又回到了 hub
当把阶段 2 的讨论套用到阶段 3 的设计上时，这个区别最关键。两场对话用的是同一批词，但对转发的影响并不相同。
这也正是变更在评审时看起来正确的原因：评审查看了路由表，而路由表只是涉及三种状态中的一种。
一次聚合，两张表
这两个操作是这样的：
| Operation | What it actually changes |
|---|---|
| Routing summary | Aggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs |
| NHRP summary map | Changes the network returned in a resolution reply, so a requesting spoke resolves to a different address |
| Protection path | IPsec state for the peer you actually resolved; neither aggregation changes it |
路由汇总是关于 hub 通告什么、接收方 spoke 以什么作为路由安装的陈述。NHRP 汇总映射是关于另一台 spoke 询问如何到达某个地址时、这台 spoke 发回的应答的陈述。这是两个不同的问题，失效方式也不同，设计可以改动其中一个，而让另一个保持原样。把它们当成同一个旋钮，正是聚合变更悄无声息变成转发变更的路径。
这两个操作都不是关于保护路径的陈述，因为保护路径是为实际解析到的对端协商的。
hub 上的汇总到底改变了什么
Cisco 关于 spoke 间 NHRP 汇总映射的指南描述了一种阶段 3 的布局：hub 通告汇总，并继续担任路由的下一跳。随后重定向和一次 NHRP 解析会提供更直接的转发路径。因此只看聚合路由并不能描述全部转发状态，也不意味着每个报文都必须永远穿过 hub。汇总讲的是可达性，而不是路径。
所以，止步于路由表的设计评审会批准一个改变解析行为的变更。请把选中的路由、NHRP 结果和保护路径当作三项独立的观测来检查。
如果你说不出三者中哪一个变了，这项变更就没有做完。
NHRP 汇总映射改变了什么
设想一台 spoke 通过若干条更具体的 LAN 路由持有 10.32.0.0/19，而 hub 向其他 spoke 通告更大的聚合。对 10.32.12.10 的请求原本会得到与之匹配的较小网络的解析信息。文档中记录的 NHRP 汇总映射功能让这台 spoke 改为返回自己配置的覆盖前缀，这可以减少属于该 spoke 的网络重复的解析工作。它并不会让 hub 的路由汇总和 spoke 的解析汇总变成同一个对象。
给这个覆盖前缀一个有意的归属模型。宽泛的应答如果包含属于别处的地址，或者包含无法到达的空洞，就可能把后续流量送到不合适的对端。
在扩大前缀之前检查真实路由和预期的拒绝情况，而不是之后。
比较第一个目的地和汇总内部的一个目的地
选两个目的地：你测试过的第一个，以及位于拟定汇总内部的另一个。对每一个记录被选中的路由、为到达它而使用的 NHRP 状态，以及真实的应答路径。这一比较会告诉你，你改变的是路由的规模、解析的规模，还是转发错误，而这是唯一有用的结论。前缀更少的显示并不能证明其中任何一项。
在把阶段 3 的示例套用到自己的网络之前，确认已部署的阶段和路由协议的下一跳行为。短小的示例并不能证明另一种设计能保持同一条直连 spoke 路径。
工单应当写明你削减了哪张表、又放过了哪张表。少写这一句，一个月后就得从头再诊断一遍。