EIGRP 邻居还是 DMVPN 穿越？先核对角色

邻居关系缺失，而中间那台路由器看起来嫌疑最大。它可能是无辜的。转发外层隧道报文与参与叠加路由协议是两件不同的事，一台设备可以只做前者而不做后者。按顺序完成下面五项检查，并在第一项不通过处停下。

第 1 步：画出两种角色

把预期的 EIGRP 邻居关系画成两台路由器之间的逻辑连接，再画出承载其隧道报文的下层（underlay）路由器。同一台设备不必同时出现在两张图里，而把两张图混为一谈，正是健康穿越路由器被冤枉破坏邻居关系的最常见原因。

穿越路由器用自己普通的 IP 路由与策略转发外层报文。它不需要运行受保护隧道内部承载的协议，也不需要 EIGRP 进程来把这些报文继续传下去。

第 2 步：确认中间设备终结了什么

如果中间路由器终结了隧道，并且本应与 spoke 建立 EIGRP 邻居关系，答案就完全不同。那台设备需要受支持的叠加路由行为，把它叫作穿越并不能免除邻居要求。先读隧道配置，再读路由配置。这个答案决定后面每一项检查。

所以第一个真正的问题不是调哪个协议，而是这台盒子究竟是 hub、spoke、纯粹的下层跳点，还是在端点之间承载帧的 Layer 2 服务。

第 3 步：核对邻居的控制平面

在每台本应成为邻居的设备上确认四件事：EIGRP 实例与自治系统号、认证参数、参与进程的接口，以及覆盖该接口的网络声明。其中任何一项不匹配，接口仍然 up、ping 仍然通，邻居关系却起不来。

RFC 7868 把 EIGRP 描述为带有组播控制交换的 IP 协议，因此邻居关系不是中间路由器靠把报文路由到某个目的地就能代理的。要么控制交换抵达对端，要么邻居关系不成立。

第 4 步：确认传输确实送达控制交换

接下来，检查叠加网络是否真的在对端之间承载控制流量。检查对端的 NHRP 映射以及到达它的外层路由，再确认隧道接口 up 且能过流量。下层 ping 通只证明外层路径存在，并不证明叠加控制交换已经送达。

透明 Layer 2 服务、点到点隧道和多点 DMVPN 云对组播的传递方式各不相同。要按实际部署的那一种，遵循受支持的接口、NHRP 与组播模型，而不是假定三者行为一致。

第 5 步：若无法参与，就重新设计边界

如果必需的叠加设备无法运行该协议，就明确改动设计。在该边界使用受支持的协议或交换模型，或者安排合适的端到端隧道，让邻居成为真正互相通信的端点。不要以为一条静态路由就能让不参与者变成每个控制报文的中继。

在图上记录每台设备的角色，并与配置一起保存。RFC 7868 对协议交换的定义，正是无法用穿越转发模拟邻居关系的依据。

五项检查全部做完后邻居关系仍不成立时，剩下的嫌疑是平台特性，例如隧道接口上的组播处理，以及过滤协议 88 的策略。这些是具体且可验证的原因，比再一轮责怪中间路由器更有价值。