DMVPN 覆盖网上 EIGRP 邻居起不来

隧道已经起来，一台分支能 ping 通另一台，可中心上 EIGRP 还是看不到任何邻居。这种组合并不神秘，而是正常现象：ping 证明的是经 NHRP 的单播可达性，而 EIGRP 的 hello 是组播。在 DMVPN 覆盖网上，路由协议的投递模型是第二个配置面，而这正是人们跳过的一面，因为第一个面看上去已经健康。下面每一层都用各自的命令检查，因此某一层出问题不会把你送回清单顶端。

先把期望的邻接关系写下来

在任何 show 命令之前，先列一张短表：哪个分支应当与哪个中心、经哪个隧道接口、在哪个 EIGRP 自治系统里建立邻居。多中心设计往往在中心之间的缝隙里出问题，而一张表能把「EIGRP 坏了」变成「3 号分支没有向 2 号中心注册」。把每条链路上期望的隧道子网也写进去，因为两端地址不一致看起来和协议故障一模一样。把清单写进工单，这样下一班人对照的是设计，而不是上一张截图。

先查 NHRP，再查组播路径

从注册状态和中心实际持有的映射开始。中心上没有动态表项的分支就是没注册，任何路由协议都补不回来。然后确认分支愿意接收来自中心 NBMA 地址的组播，这和 NHS 表项是两行不同的配置。

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

ip nhrp map multicast 这一行让分支能把 hello 以复制组播的方式经覆盖网发给中心，也让中心的组播能到达已注册的分支。没有它，经 NHRP 的单播通、组播不通，而正是这种落差让 ping 看起来像证据。Cisco 的 IOS XE DMVPN 指南 按阶段记录了中心与分支的组播行为，所以请把配置对齐到你实际部署的那个阶段，而不是从别的拓扑里抄一段。

查 EIGRP 自己的接口策略

不在 EIGRP 进程里、或者被设为 passive 的隧道，无论覆盖网多健康都不会形成邻接。把接口的参与情况和邻居表放在一起读，因为前者解释了后者。

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

认证和度量权重必须两端一致。密钥链模式不对，或者 K 值不匹配，都会让 hello 被丢弃，而接收端不一定有显眼的 syslog 行。如果设计使用显式配置的单播邻居，就完整照那套模型走，而不是在组播设置上层层叠加直到碰巧起来。

把 GRE 承载和 IPsec 保护分开看

DMVPN 在 GRE 里承载组播，IPsec 保护的是 GRE 包，而不是直接保护内层组播。所以「IPsec 不能承载组播」这种笼统说法在这个设计里是错的，作为诊断也没有用。请把隧道上的 IPsec 配置、各邻居的安全联盟、以及隧道接口状态当作三件独立的事实来查。

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

如果 SA 已建立、计数器在增长，而 EIGRP 仍然不起来，就该把排查往协议栈上层挪：包已经被保护并送达，问题在于协议选择发哪些包。

要验证路由，而不只是邻居数量

邻接一旦建立，就去看它宣告了什么、装进了什么。在多点隧道上，水平分割和下一跳行为决定一台分支能否经中心到达另一台分支；而聚合会在邻居关系完好的情况下把某个前缀藏起来。

最后用两个站点之间一个被放行的应用来收尾，并确认它走的路由。分支到分支的直连捷径是一项转发需求，有它自己的 NHRP 和安全状态；为了让邻居数好看而加上它，通常会带来第二个问题。

把分阶段的设计、组播映射和 EIGRP 策略记在一个地方。下一位工程师需要的是设计，而不是转录稿。