DMVPN 第 3 阶段：双向读取捷径

你看到一个 ping 从分支到分支，走了经过中心的远路，第二个却直接过去。此时很容易宣布捷径已经生效。这个结论只对了一半。去程可能是捷径，而回程仍走中心，而且证明每个方向的状态是不同的状态。在接受该设计为健康之前，请把两个方向都走一遍，并读取三张表。

从你真正能看到的报文路径开始

从一个本应直连的分支出发。跟踪第一个报文：它沿着分支的路由走向中心，因为此时还没有捷径。中心将其转发，并且在第 3 阶段设计中还会向源发送重定向，说明存在更优路径。

那个重定向是触发条件，不是证据。它只说明中心看到了可以优化的流量。它并不说明源已建立捷径、目的端已回应该解析，也不说明回程使用了捷径。

因此第一个有用的观察是前后对比：第一条流经过中心，后来的流直接走。

三个看起来像同一条隧道的状态

捷径依赖三段状态，每一段都有自己的生存期和自己的命令。

NHRP 缓存条目把 overlay 地址映射到 NBMA 传输地址。路由或捷径决定某个内网目的地被转发到哪里。IPsec 关联保护由此产生的任何流量。缺失的回应可能来自这三者中的任何一个，而命令会告诉你缺的是哪一个。

按这个顺序读，因为缺少映射会让另外两者变得没有意义。

把请求和回应分开走一遍

从分支 A 请求解析，观察返回什么。请求走受支持的 NHRP 转发路径，而目的端可以直连回应，而不必经过中心。这种不对称是正常的，也正因如此回应才是这次交换中有趣的那一半。

现在交换角色。从 B 发往 A，重复同样的三次读取。只给一个方向做捷径、另一个方向不做的设计并不对称，而不对称通常来自某一侧缺少前缀，或来自始终没有得到回应的解析。

对端的回应不必仅仅因为请求经过了中心就也经过中心。不要把这一点读成错误，也不要去追查并不存在的路由故障。

读中心的重定向，而不只是它的路由

中心的路由表告诉你中心会把报文发往哪里。重定向告诉你中心要求源对此做什么。这是两个不同的事实，而一个路由正确却不发重定向的中心会让每条流一直走远路。检查中心的 NHRP 事件，并确认针对你关心的流量确实生成了重定向。

第 3 阶段也改变了汇总的含义。在捷径行为下，分支不再需要第 2 阶段设计所期望的那整套具体远端路由，因此分支上的汇总路由并不自动等于缺失的网络。在把汇总读成故障之前，先确认阶段和路由策略。

正是这一个误解，造成的 DMVPN 工单比其他任何原因都多。

把结论记录为缺失的对象

以一个被授权的应用流及其回应收尾，并记录每个方向是否走了直连路径。然后把结论写成那个缺失的对象：一条映射、一条转发捷径、一个保护关联，或者一个应用回应。

路由邻接和共享的安全关联是健康的证据，不是路径的证据。两者都可以完美，而每个报文仍然绕远路。先检查转发决策，再检查承载它的关联。顺序很重要，因为关联无论如何都会建立。

这个习惯在下一张工单上就会见效。「隧道起来了但很慢」会变成「B 没有通往 A 主机的捷径」，而第二种说法是五分钟就能修好的事。把命令输出和结论放在一起，并把厂商的第 3 阶段操作指南放在旁边。