分层 DMVPN：每条隧道关系一个云

一个分支节点成功注册到区域枢纽，却仍然无法访问另一区域的服务。隧道处于运行状态，NHS 状态看起来健康，故障只出现在跨越层边界的目的地。这种模式通常意味着设计从未说明哪些设备参与哪个 DMVPN 云，因此各层是凭直觉搭建的，如今彼此不符。

症状出现在层边界

在分层设计中，中心枢纽、若干区域枢纽和许多分支节点各自占据一个位置。区域枢纽可以拥有不止一条隧道关系，分支也不必向每个中心端点注册。真正重要的路径是分支到区域服务、分支到另一个获批的区域节点，以及分支到中心目的地。

当其中一条路径失败而其他路径正常时，问题几乎总是角色定义缺失或冲突，而不是隧道损坏。把预期路径写下来，与设备实际构建的结果对比。这项对比花一小时，却省下一周的猜测。把它和设计文档放在一起。

一个云，一份接口契约

对每个云，记录隧道接口、叠加层编址、本地底层源、NHS 与 NBMA 关系、组播投递和保护策略。还要写明哪些路由在区域与中心上下文之间穿行，因为那句话就是设计本身。

具有两个隧道接口的区域枢纽需要两份契约，而不是一份带两个地址的契约。底层源、NHRP 域和路由可能因接口而异，把二者合并的文档会误导配置第二个接口的人。

标识符是本地上下文，不是访问控制

NHRP 网络 ID 和 GRE 密钥是最常被误认为全局设置的两个值。IOS XE 的 NHRP 指南把网络 ID 描述为本地有效，因此远端路由器上数字相同并不能认证任何东西，改动一台路由器的本地编号也不会形成访问边界。

GRE 密钥在设计使用它时，有助于识别接收侧隧道的上下文，并由共享该上下文的端点协商。它不是密码，也不替代 IKE 认证或路由策略。把这两个值当作关系内必须一致的配置上下文，而不是分隔区域的安全控制。

有意识地在层间路由

决定区域枢纽向上通告哪些前缀，以及向分支提供哪些中心目的地。然后检查每条路径实际的下一跳和阶段相关的捷径行为，因为汇总路由和捷径可能产生与示意图暗示大不相同的转发。

用路由和访问策略来强制区域隔离。如果分支不应直接到达另一区域，就应由路由和策略来说明，而不是依赖一个从未为此设计的标识符。把策略写在标识符旁边。否则下一位工程师会以为编号在起作用。

诊断意外的捷径

当分支试图与中心端点建立直接关系时，先检查它的路由、NHRP 映射和所选隧道上下文，再随意更改标识符。可达性缺失、非预期的 NHS 关系和合法但未获授权的捷径，需要三种不同的修正。

DMVPN 配置指南把隧道和 NHRP 设置放在一起展示，正因如此才需要先在纸面上划清范围。记录云端契约，保持各层路由明确，下一次边界故障就有地方可指。