OSPF 邻居在 VPN 上建立不起来？按顺序检查这几项

隧道已建立，接口位于同一子网，OSPF 却什么都不显示。多数情况下隧道没问题，而是 OSPF 的某一项要求未满足。按顺序完成下面五项检查，并在第一个失败处停下。

每项检查的症状各不相同，所以顺序比清单本身更重要。

检查 1：链路模型是否正确

点对点接口与共享多路访问网络是不同的 OSPF 环境。把广播型 LAN 配置照搬到隧道上，是这里最常见的错误。设置 VPN 实现所支持的网络类型，路由型隧道通常是点对点。然后确认平台也认同，因为有些实现会忽略或覆盖该设置。

如果链路模型错了，清单后面的内容都帮不上忙。

检查 2：报文是否被放行

OSPFv2 是 IP 协议 89，而不是 TCP 或 UDP 端口，所以按端口编写的防火墙规则会静默丢弃它。Hello 还发往组播地址，策略可能不允许。在隧道两端之间放行协议 89，然后确认平台是否需要显式的邻居声明。

只放通 ping 的隧道是策略问题，而不是路由问题。

检查 3：邻居参数是否一致

区域 ID、hello 与 dead 间隔、认证以及 stub 标志都必须一致。不一致通常会让邻居停在可见状态，而不是静默失败，这反而有用。要比较两端正在运行的配置，而不是计划中的配置。

MTU 不一致是隐蔽的一项。它会在 ExStart 阶段阻断数据库交换，邻居因此永远到不了 Full。

检查 4：状态说明了什么

状态会点明故障。Init 表示 hello 已到达，但本路由器未被列入其中，指向单向路径或组播问题。Two-Way 在带有非 DR 邻居的广播网段上是正常的，在点对点链路上则不正常。ExStart 或 Exchange 卡住意味着 MTU 或数据库描述有问题。Loading 意味着链路状态请求没有得到应答。

在改动任何东西之前先读状态，因为它能排除清单上的大部分可能。

show ip ospf neighbor 会打印状态、邻居地址和 dead 计时器。把这个计时器与两侧的 hello 间隔对比：dead 为 hello 的四倍属正常，其他任何情况都是不一致。状态列是全页最快的读法。

检查 5：实际宣告了什么

Full 邻接不等于有路由。检查哪些网络被产生、哪些被学到、哪些被装入路由表。缺少 network 语句，或重分发策略排除了站点前缀，就会得到健康的邻居和空表。

然后测试主机级应用和回程路径，因为路由协议并不会打开防火墙。

对于 IPv6，OSPFv3 有自己的要求，并不是每个 OSPFv2 设置上的地址族开关。请使用对应的协议和平台文档。如果连接只是一条固定链路，那么在增加一个必须运维的控制平面之前，先比较静态路由。