第52篇：OSPF 邻居状态机——从 Down 到 Full
关键词
OSPF、邻居状态机、Down、Init、2-Way、ExStart、Exchange、Loading、Full
一、OSPF 邻居状态总览
OSPF 在建立邻居（Neighbor）和邻接（Adjacency）时，有一套标准的状态机。一共 8 个状态，从初始的 Down 到最终的 Full：
Down → Init → 2-Way → ExStart → Exchange → Loading → Full
↓（backup）
2-Way（DRother 之间）
并不是所有邻居都必须到达 Full 状态。部分邻居停留在 2-Way 即可。
二、各状态详解
2.1 Down 状态
初始状态。路由器还没有收到来自这个邻居的任何信息。
在这个状态下，路由器会向组播地址 224.0.0.5（AllSPFRouters）发送 Hello 报文。
2.2 Init 状态
路由器从某个接口收到了 Hello 报文，但在该报文的 Neighbor 字段中没有看到自己的 Router-ID。
通俗理解：我知道你存在，但你还没看到我。
2.3 2-Way 状态
路由器收到 Hello 报文，并且在该报文的 Neighbor 字段中看到了自己的 Router-ID。
双方互相发现，双向通信建立。
在 2-Way 状态，会发生一件重要的事情——DR/BDR 选举（广播网络和 NBMA 网络中）。
对于 DRother（既不是 DR 也不是 BDR）路由器之间的邻居关系，状态停留在 2-Way，不再继续。这是正常现象，不是故障。
2.4 ExStart 状态
在广播网络中，DR 和 BDR 会与所有邻居进入 ExStart 状态，准备交换链路状态信息。
这一阶段的主要目的是协商主从关系（Master/Slave）： - Router-ID 大的成为 Master - Master 控制 DD 报文的发送时序
2.5 Exchange 状态
路由器开始交换 DBD（Database Description）报文，也就是 LSDB 的"摘要"。
DBD 报文不包含完整的 LSA 内容，只包含 LSA 的头部信息（类型、通告者、序列号等）。
双方通过 DBD 报文对比自己的 LSDB，找出自己缺少的或更新的 LSA。
2.6 Loading 状态
发现对方有自己需要的 LSA 后，进入 Loading 状态：
- 发送 LSR（Link State Request） 报文请求完整的 LSA
- 对方回复 LSU（Link State Update） 报文携带完整 LSA
- 收到后回复 LSAck 确认
完整的 LSA 内容只在 LSU 中传输。
2.7 Full 状态
邻接关系正式建立。
双方的 LSDB 已经同步完成，保持一致。Full 状态是 OSPF 邻接的最终稳定状态。
三、状态迁移全过程图解
RouterA（RID=1.1.1.1） RouterB（RID=2.2.2.2）
│ │
│ Hello（RID=1.1.1.1） │ Down
│─────────────────────────────►│ → Init
│ │
│ Hello（Neighbor=1.1.1.1） │
│◄─────────────────────────────│ → 2-Way
│ │
│ DBD（Master协商） │ → ExStart
│◄════════════════════════════►│ （Master=2.2.2.2）
│ │
│ DBD（LSA 摘要交换） │ → Exchange
│◄════════════════════════════►│
│ │
│ LSR（请求缺少的 LSA） │ → Loading
│─────────────────────────────►│
│ LSU（完整 LSA） │
│◄─────────────────────────────│
│ LSAck │
│─────────────────────────────►│
│ │
│ Full │ → Full
四、哪些设备需要 Full 状态？
| 网络类型 | 建立 Full 邻接的关系 |
|---|---|
| 广播网络 | DR <-> 所有路由器、BDR <-> 所有路由器 |
| 广播网络 | DRother <-> DR、DRother <-> BDR |
| 广播网络 | DRother <-> DRother（停留 2-Way，不建 Full） |
| P2P 网络 | 两台路由器之间建立 Full |
重要理解：2-Way 是正常的邻居状态，不是故障。 在广播网络中，大量 DRother 之间停留在 2-Way 是 OSPF 的设计，目的是减少不必要的邻接数。
五、常见卡住状态分析
| 卡住状态 | 可能原因 | 排查方向 |
|---|---|---|
| Init | 自己发出的 Hello 不被对方收到 | 检查接口是否 up、ACL 过滤、组播地址 |
| 2-Way 卡住（预期外） | 本应为 DR/BDR 的设备未建立邻接 | 检查 DR 选举、优先级配置 |
| ExStart/Init | MTU 不匹配 | 检查两端接口 MTU 是否一致 |
| ExStart 死循环 | Router-ID 相同或接口类型不匹配 | 检查 Router-ID、网络类型 |
| Loading 卡住 | LSU 不响应 | 检查 LSDB 是否过大、设备 CPU |
| 反复振荡 | 物理不稳定或参数不匹配 | 检查 Hello/Dead 间隔、认证 |
六、验证命令
# 查看 OSPF 邻居
display ospf peer
# 查看邻居详细信息
display ospf peer verbose
# 查看 OSPF 接口状态
display ospf interface
# 查看 LSDB
display ospf lsdb
七、总结
| 状态 | 含义 | 关键事件 |
|---|---|---|
| Down | 未收到任何信息 | 开始发送 Hello |
| Init | 收到 Hello 但自己不在其中 | 邻居发现 |
| 2-Way | 双向通信建立 | DR/BDR 选举 |
| ExStart | 协商主从关系 | Master 确定 |
| Exchange | 交换 LSA 摘要 | DBD 报文交互 |
| Loading | 请求完整 LSA | LSR/LSU/LSAck |
| Full | LSDB 完全同步 | 邻接建立成功 |
八、思考
- 为什么 DRother 之间不需要 Full 状态？
- MTU 不匹配会导致哪个状态卡住？
- 看到邻居在 2-Way 状态，是故障吗？为什么？
- DBD 报文包含 LSA 的哪些信息？为什么只发头部？
- 什么是 Master/Slave 协商？谁成为 Master？
下篇预告：第53篇《OSPF Hello 报文与邻居建立条件》——详解 OSPF 邻居建立的各项参数匹配条件。