关键词：OSPF、故障排查、邻居状态、Init状态、ExStart状态、DBD、MTU
第67篇：OSPF 邻居故障排查：状态卡在 Init/ExStart
一、引言
OSPF 邻居关系建立失败是网络工程师最常见的故障场景之一。邻居状态卡在某些中间状态（如 Init、ExStart、Exchange）而非正常达到 Full，意味着 OSPF 的某个建立步骤受阻。
掌握 OSPF 邻居状态的排查方法，首先需要理解每个状态的含义和进入该状态的条件。状态卡在某个位置，说明满足了进入该状态的条件，但不满足继续向前迁移的条件。沿着状态机的方向逐层排查，可以快速定位故障根因。
二、核心概念
2.1 常见卡点状态及含义
| 卡点状态 | 说明 | 典型原因 |
|---|---|---|
| Down | 未收到有效 Hello | 物理故障、OSPF未使能、Hello被过滤 |
| Init | 收到 Hello 但未看到自己 | 单向通信、ACL过滤对方Hello |
| 2-Way | 双向已建立但不继续 | DROther间正常；网络类型不匹配 |
| ExStart | Master/Slave协商失败 | MTU不匹配、DBD报文问题 |
| Exchange | DBD交换未完成 | 区域不一致、LSA问题 |
| Loading | LSA请求未完成 | 链路丢包、LSA过大 |
2.2 排查方法论
OSPF 邻居故障排查遵循"由外到内、由底到顶"的原则：
三、技术细节
3.1 卡在 Init 状态的排查
状态含义：路由器收到了对方的 Hello 报文，但在 Hello 的 Neighbor List 中没有看到自己的 Router ID。
排查步骤：
| 步骤 | 检查项 | 命令 |
|---|---|---|
| 1 | 双方接口 IP 是否在同一网段 | display ip interface brief |
| 2 | 对方是否收到了本端的 Hello | 抓包分析 |
| 3 | 是否存在 ACL 过滤 | display acl all |
| 4 | Hello 间隔/Dead 间隔是否匹配 | display ospf interface |
| 5 | Area ID 是否一致 | display ospf interface |
| 6 | 认证是否匹配 | display current-configuration |
| 7 | 网络类型是否一致 | display ospf interface |
3.2 卡在 ExStart 状态的排查
状态含义：双向通信已建立，但在 Master/Slave 协商阶段（交换 DBD 报文）受阻。
排查步骤：
| 步骤 | 检查项 | 命令 |
|---|---|---|
| 1 | 接口 MTU 是否一致 | display interface |
| 2 | DBD 报文是否被丢弃 | debugging ospf packet dbd |
| 3 | OSPF MTU 检查是否启用 | display ospf interface |
| 4 | 链路是否存在严重丢包 | ping 测试 |
| 5 | 接口是否配置了 OSPF MTU ignore | display current-configuration |
ExStart 卡点最常见原因：MTU 不匹配。DBD 报文可能携带较大的 LSA 摘要信息，如果接收方接口的 MTU 小于 DBD 报文大小，且 IP 报文不允许分片（DF 位设置），则报文被丢弃。
3.3 关键调试命令
# 开启OSPF事件调试
debugging ospf events
# 开启OSPF报文调试
debugging ospf packet hello
debugging ospf packet dbd
debugging ospf packet lsr
debugging ospf packet lsu
debugging ospf packet lsack
# 开启所有OSPF调试
debugging ospf all
# 终端监视调试输出
terminal monitoring
terminal monitor
四、实战配置/案例分析
4.1 案例一：卡在 Init 状态——ACL 过滤
故障现象：R1 与 R2 的 OSPF 邻居状态卡在 Init。
排查过程：
- 检查 R1 的状态：
[R1] display ospf peer
Neighbor
Neighbor ID: 2.2.2.2
Negotiation: Init/Init
-
抓包分析：R1 能收到 R2 的 Hello，但 R2 的 Hello 中 Neighbor List 没有 R1 的 Router ID。
-
检查 R2 是否收到 R1 的 Hello——在 R2 上抓包，发现 R2 没有收到 R1 的 Hello。
-
检查 R2 接口的入方向 ACL：
[R2] display acl 3000
ACL 3000, name "inbound-filter"
rule 5 deny ip source 10.1.1.1 0
rule 10 permit ip
-
根因：ACL 3000 拒绝源地址为 R1 的报文，导致 R1 的 Hello 无法到达 R2。
-
修复：
[R2] acl 3000
[R2-acl-adv-3000] undo rule 5
# 或
[R2-acl-adv-3000] rule 5 permit ip source 10.1.1.1 0
4.2 案例二：卡在 ExStart 状态——MTU 不匹配
故障现象：R1 与 R2 的 OSPF 邻居状态在 ExStart 和 2-Way 之间震荡。
排查过程：
- 检查邻居状态：
[R1] display ospf peer verbose
Neighbor ID: 2.2.2.2
State: ExStart
State Info: InexStart
- 检查接口 MTU：
[R1] display interface GigabitEthernet 0/0/1
Current system uptime: 1 day, 2 hours
...
Output Queue: size 1000, depth 0
...
MTU: 1500 Bytes
[R2] display interface GigabitEthernet 0/0/1
MTU: 9000 Bytes # Jumbo Frame
- 开启 DBD 调试：
[R1] debugging ospf packet dbd
# 观察到DBD持续重传但无确认
-
根因：R2 发送的 DBD 报文超过了 R1 接口的 MTU，R1 丢弃了该报文。
-
修复方案（任选其一）：
# 方案1：统一MTU
[R2] interface GigabitEthernet 0/0/1
[R2-GigabitEthernet0/0/1] ip mtu 1500
# 方案2：忽略OSPF MTU检查
[R1] interface GigabitEthernet 0/0/1
[R1-GigabitEthernet0/0/1] ospf mtu-ignore
[R2] interface GigabitEthernet 0/0/1
[R2-GigabitEthernet0/0/1] ospf mtu-ignore
4.3 案例三：一端 Init 一端 Down
故障现象：R1 显示邻居为 Init，R2 显示没有该邻居。
分析：R1 收到了 R2 的 Hello，但 R2 没有收到 R1 的 Hello。这是典型的单向通信问题。
排查方向： 1. 检查 R2 接口的入方向是否有 ACL 或防火墙规则 2. 检查中间网络设备（交换机、防火墙）是否有不对称的过滤策略 3. 检查组播路由是否正常（224.0.0.5）
五、总结
| 卡点状态 | 首选排查方向 |
|---|---|
| Down | 物理链路 → OSPF 进程 → 接口宣告 |
| Init | 单向通信 → ACL 过滤 → 组播可达性 |
| ExStart | MTU 不匹配 → DBD 报文 → 链路丢包 |
| Exchange | 区域不一致 → LSA 问题 → 认证 |
| Loading | 链路丢包 → LSA 过大 → 资源不足 |
思考
- 为什么 OSPF 邻居卡在 Init 状态通常意味着单向通信问题？如果通信是双向的，邻居状态为什么会停留在 Init？
- MTU 不匹配为什么会影响 ExStart 状态而不是 Init 状态？ExStart 阶段交换的 DBD 报文与 Hello 报文在大小上有何差异？
- 在排查 OSPF 邻居故障时，为什么建议先检查物理链路和 IP 连通性，再检查 OSPF 配置参数？
下篇预告：第68篇：OSPF 邻接震荡典型案例分析