OSPF邻居卡在ExStart或Exchange:MTU与DBD排查指南
先在两端同时保存邻居详细状态、接口 OSPF 参数、实际二层 MTU、Router ID、网络类型、Hello/Dead 时间、区域、认证和日志。ExStart/mtu-ignore。确认 Router ID 唯一、两端网络类型一致、没有单向 ACL,并在修复后验证邻居到 Full、LSDB 摘要一致且路由稳定。
本文目录(19 节)
直接答案
先在两端同时保存邻居详细状态、接口 OSPF 参数、实际二层 MTU、Router ID、网络类型、Hello/Dead 时间、区域、认证和日志。ExStart/mtu-ignore。确认 Router ID 唯一、两端网络类型一致、没有单向 ACL,并在修复后验证邻居到 Full、LSDB 摘要一致且路由稳定。
一、先确认邻居停在哪个状态
使用 FRR 可执行:
show ip ospf neighbor detail
show ip ospf interface
show ip ospf database
show ip ospf
记录状态持续时间、state change 次数、邻居/本地 Router ID、接口、DR/BDR、事件与重传。Init 表示只单向看到 Hello;2-Way 在广播网络的 DROther 之间可能是正常最终状态;ExStart/
二、理解ExStart与Exchange阶段
ExStart 阶段双方决定主从关系并选择初始 DBD 序列号;Exchange 阶段按序列交换数据库摘要。主/从角色由 Router ID 等协议规则决定,不是接口主备或业务优先级。DBD 标志、序列或角色认知不一致会导致重新协商。
日志若反复出现 negotiation done 后又 sequence mismatch、ExchangeDone 后重置,保存每次 DBD 的方向和序列。不要只看最终邻居状态快照,因为快速抖动会让真正的重置原因消失。
三、同时比较两端实际MTU
检查物理接口、VLAN 子接口、bond、隧道与虚拟接口的 MTU:
ip link show
设备 CLI 同时查看运行配置和接口实际值。封装链路可能一端配置 1500、另一端 1492/1400;交换机端口允许 jumbo 不等于路由子接口实际 MTU 一致。DBD 报文携带接口 MTU 信息,接收端可因不匹配拒绝继续。
四、不要滥用mtu-ignore
FRR 和部分设备提供忽略 OSPF MTU 检查的配置,可用于特定兼容场景或短时验证。但若真实路径无法传输较大的 LSA/数据包,邻居即使 Full,后续 LSDB 同步和业务转发仍可能失败。
先确认底层链路、隧道开销和所有中间设备支持的 MTU,优先统一接口值。只有路径实际承载能力足够、差异源于已知控制面实现时,才在变更记录中使用忽略选项并做大包与 LSDB 回归。
五、检查网络类型是否一致
OSPF broadcast、point-to-point、NBMA 和 point-
两端读取接口实际 network type,不要只按介质猜测。隧道、子接口和厂商默认可能不同。修正类型后确认 Hello/Dead interval、DR/BDR 与链路拓扑符合设计。
六、Router ID必须唯一且稳定
重复 Router ID 会让 LSDB 节点身份冲突,邻居关系和 LSA 处理异常。列出整个 OSPF 域内 Router ID,不只比较当前两端。Router ID 若随接口地址和进程重启变化,也会造成邻接重建。
为路由器配置明确、唯一且稳定的 Router ID,并纳入地址管理。修改通常需要重启/clear OSPF 进程才能生效,会影响全部邻居,应在维护窗口分批执行。
七、核对Area与接口参数
同链路两端必须在兼容区域与参数下建立邻接。检查 area ID、stub/NSSA 相关能力、Hello/Dead interval、认证类型与 key、以及必要 option bits。Hello 能到 2-Way说明部分参数已兼容,但实现与日志仍可能在后续暴露选项不一致。
比较运行状态而非模板配置。Route-map 或接口继承、VRF 和多实例可能让同一物理接口属于不同 OSPF 进程。
八、认证问题要看双向日志
认证 key、类型、key ID 或时间有效范围不一致通常会阻止邻接,但某些轮换边界和实现行为可能造成会话抖动。记录两端认证失败计数和时间,确认系统时钟、重叠轮换窗口与接口实际配置。
不要在抓包、工单和普通日志中暴露密钥。可比较 key ID、算法和配置哈希;必要时在隔离实验链路使用临时测试,而不是生产中关闭认证。
九、确认IP Protocol 89双向可达
OSPF 直接使用 IP protocol 89,不是 TCP/UDP 端口。主机防火墙、云安全组、ACL、CoPP 或隧道策略可能允许组播 Hello,却丢弃较大单播/组播 DBD,造成停在 ExStart/
在两端接口同时抓取:
tcpdump -ni INTERFACE 'ip proto 89'
比较同一报文是否从 A 发出并在 B 收到、B 响应是否返回。远程抓包要限制时长和大小,并遵守生产授权。
十、检查单向链路与二层异常
光模块、LAG 成员、VLAN 允许列表、MTU 黑洞和错误计数可能让小 Hello 正常、大 DBD 丢失。查看接口 input/output errors、drops、CRC、队列、LACP 和交换机两端 VLAN/MTU。
若只有特定哈希流或某个 LAG 成员失败,邻居会间歇重置。逐成员计数和受控测试比反复 clear OSPF 更能定位。
十一、DBD重传与序列不匹配
抓包检查 I(Init)、M(More)、MS(Master/Slave)位和 DBD 序列是否按预期推进。重复发送同一序列可能表示未收到确认;双方都坚持主角色或序列突然跳变则查 Router ID、进程重启和实现兼容。
保存邻接事件日志与进程 uptime。设备 CPU 高、控制平面限速或 OSPF 线程阻塞也会导致 Dead timer 和重传,不能只归因于线路。
十二、LSDB规模和资源压力
邻居从 ExStart 进入 Exchange 后,大型 LSDB 会产生多个 DBD、LS Request 和 LS Update。CPU、内存、控制面 policing 或输出队列不足可能让同步超时。查看 OSPF 进程资源、LSA 数、重传列表和 SPF/LSA 事件频率。
如果每次快到 Full 又因大量更新重置,查是否存在 LSA 泛洪风暴、接口抖动或错误重分发。不要简单加大 dead interval掩盖控制面过载。
十三、VRF与源地址路径
多 VRF 环境要确认接口、OSPF 实例、抓包和查看命令处于同一 VRF。DBD 响应若从错误源地址或路由表返回,会表现为单向。检查 FRR zebra 与内核接口/VRF 绑定、地址和路由。
不要只在 default VRF 用 ping 推断 OSPF 链路正常。使用绑定接口/VRF的诊断命令,并验证邻居源地址是链路预期地址。
十四、变更与清邻居要受控
修改 MTU、network type、Router ID 或认证都会重建邻接。一次只在 canary 链路变更,保存前后邻居、LSDB 和路由差异。clear ip ospf process 影响范围可能远大于单接口,不应作为常规“刷新”。
优先等待协议自然恢复或只清受控邻居(若实现支持且明确影响)。维护窗口内监控收敛时间、丢包和冗余路径,失败立即回滚。
十五、修复后的验收清单
确认邻居连续保持 Full(仅应为 2-Way 的拓扑除外),state change 计数不再增长,DBD/LS retransmission 清空。比较两端区域 LSDB checksum/条目、路由表、下一跳和预期前缀,执行小包与接近路径 MTU 的业务测试。
重启单端 OSPF 进程或接口的演练应在授权窗口进行,确认能在目标时间重新 Full。监控邻居状态、重传、接口错误、控制面丢包、LSA 数和收敛耗时;配置审计自动检查 MTU、network type 与 Router ID 唯一性。
常见问题 FAQ
OSPF卡ExStart最常见原因是什么?
接口 MTU 不一致非常常见,但不是唯一原因。还要检查网络类型、Router ID、DBD序列、ACL和单向链路。
开启mtu-ignore就算修好了吗?
不一定。它可能让邻居继续,但真实路径仍无法承载大包。优先统一 MTU,并验证 LSDB 和业务大包。
2-Way为什么不一定是故障?
广播网络中两个 DROther 之间通常保持 2-Way,不建立 Full 邻接。要结合双方角色和拓扑判断。
OSPF使用哪个端口?
OSPF 使用 IP protocol 89,不是 TCP/UDP 端口。ACL和抓包过滤应按协议号处理。
修改Router ID后为什么没有变化?
运行中的 OSPF 进程可能仍使用旧 Router ID,需要受控重启/clear 后生效。该操作会重建多个邻居,必须评估影响。
总结
OSPF 卡在 ExStart/
官方资料
- RFC 2328:OSPF Version 2:https:
/ / www. rfc- editor. org/ rfc/ rfc2328 - FRRouting:OSPFv2:https:
/ / docs. frrouting. org/ en/ latest/ ospfd. html - FRRouting:Zebra:https:
/ / docs. frrouting. org/ en/ latest/ zebra. html - FRRouting:VTY shell:https:
/ / docs. frrouting. org/ en/ latest/ vtysh. html