OSPF邻居一翻动全网就断？邻居状态机抖动的三大源头逐个排查

凌晨收到告警，分公司那边的业务系统一阵能连、一阵连不上。登上核心路由器敲下 display ospf peer，本来应该稳定在 Full 的邻居状态，正在 Full、ExStart、Down 之间来回跳——邻居一翻动，整段路由跟着重建，业务当然时断时续。这种「配好了、也曾经跑得好好的，突然开始抖」的故障，和「邻居从来没建立起来」是两类问题，排查的切入点完全不同。

先看懂状态机在说什么

OSPF 邻居从 Hello 报文相识，经过协商、同步，最终到 Full 状态才算真正可用。平时它安安静静待在 Full；一旦你看到它在 ExStart 或 Down 上反复横跳，意思是邻接关系在不断地拆了又建。每一次拆建，路由都要重新计算一遍，网络自然跟着震荡。所以处理思路不是急着改配置，而是先回答一个问题：是谁在反复把它推倒？

三大源头挨个对

第一，MTU 不匹配，卡在 ExStart。两台设备的接口 MTU 不一致时，邻居能起个头，却会在数据库同步阶段谈不拢——典型的表现就是状态停在 ExStart 上不去，或者上去又掉下来。两端接口的 MTU 逐一对齐，这是翻动嫌疑榜上的头号嫌疑。

第二，Hello/Dead 定时器不一致。OSPF 靠周期性的 Hello 维持邻居关系，两端 Hello 或 Dead 时间配得不一样，一边觉得对方还活着、另一边已经判了死亡，状态自然来回跳。检查两端接口的定时器配置，必须完全一致。

第三，网络类型不匹配。一端接口配成广播型（broadcast），另一端配成点对点（p2p），报文能收到、邻居却总对不齐，同样表现为翻动。用 display ospf interface 看两端接口的 OSPF 网络类型，对不上就统一。

一条命令看错包计数

三个源头不用瞎猜，display ospf error 把收到的错误报文按原因分类计数：认证失败的计数在涨，去查两端认证配置；网络类型不符的计数在涨，去对网络类型。哪一类计数持续增加，方向就指向哪里，比反复盯着状态表看高效得多。

别忘了次生现象

邻居翻动还有一笔连带账：每次拆建都触发 SPF 重新计算，CPU 占用会跟着抬高。如果你先看到的是路由器 CPU 忽高忽低，顺着去查邻居状态，往往能找到同一个根源——翻动治好，CPU 自然回落。

贵州诚鑫致达科技在帮客户维护多分支机构互联的骨干网时，处理这类故障的固定顺序就是：先 display ospf peer 确认翻动模式，再用 display ospf error 的计数锁定源头，最后才动配置。邻居曾经建立过、后来开始抖，按这三源头排查基本都能收口；如果是从一开始就建立不起来，那是另一类问题，走的排查路径也不一样。

企业存储选型参考｜贵州诚鑫致达

老机型数据迁移与扩容（DS218+/DS420+/DS3622xs+ 等），群晖机型参考：可衔接 SA3410 · UC3400 · RS2423RP+。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。