在 OSPF 邻居关系建立的过程中，从 ExStart 状态到 Full 状态的演变是整个协议最核心的数据库同步阶段。这一阶段决定了 OSPF 链路状态数据库（LSDB）的一致性。

以下是基于 RFC 2328 标准及华为 VRP 实现的详细技术分解：

1. ExStart 到 Full 的 DD 报文交互详解

一旦邻居状态到达 ExStart ，路由器便开始通过 DD（Database Description）报文进行交互。

Step 1: ExStart 状态 — 主备选举

  • 交互逻辑 ：双方发送“空”的 DD 报文（不包含 LSA 摘要），试图确定 Master/Slave 关系。
  • 关键标志位 ：此时 DD 报文的 $I=1$（Init），$M=1$（More），$MS=1$（Master）。
  • 选举规则 ：比较 Router ID ，大者为 Master。Master 负责控制 DD 报文的 Sequence Number （序列号）。

Step 2: Exchange 状态 — 摘要交换

  • 交互逻辑 ：主备关系确定后，进入 Exchange 状态。Slave 使用 Master 的序列号发送包含自身 LSDB 摘要的 DD 报文。
  • 确认机制 ：Master 每发送一个序列号，Slave 必须用相同的序列号进行应答。
  • 标志位 ：当一方发送完最后一包摘要时，$M$ 位清零（$M=0$）。

Step 3: Loading 状态 — 详细信息同步

  • 交互逻辑 ：对比 DD 报文发现本地缺失的 LSA，路由器发送 LSR （Link State Request）。
  • 更新过程 ：对端回应 LSU （Link State Update），本端收到后回复 LSAck （Link State Acknowledgment）。
  • 状态标志 ：此阶段接口在不断请求和加载拓扑细节。

Step 4: Full 状态 — 完全同步

  • 当所有的 LSR 队列都已被清空，且收到所有请求的 LSU 后，邻居关系跃迁至 Full 。这意味着两台路由器的 LSDB 已达到逻辑上的完全同步。

2. MTU 不匹配的故障现象

在 OSPF 报文头部，DD 报文包含一个 Interface MTU 字段。

停留状态：ExStart / Exchange

如果两端 MTU 配置不一致，状态机通常会卡在 ExStart 或 Exchange 状态：

  1. 华为默认行为 ： 华为设备默认不检查 DD 报文中的 MTU 字段（填充值为 0）。在这种情况下，即使物理层 MTU 不匹配，OSPF 也能到达 Full。但是，如果后续发送的大尺寸 LSU 超过了链路实际 MTU，会导致大包丢弃，邻居关系会频繁在 Loading 和 Full 之间震荡。
  2. 开启 MTU 检查后 （配置 ospf mtu-enable）：
  • Master 的 MTU > Slave 的 MTU ：Slave 收到 Master 的 DD 报文后，发现 MTU 太大，会卡在 ExStart 状态。
  • Master 的 MTU < Slave 的 MTU ：Master 收到 Slave 的 DD 报文后，会由于 MTU 检查失败，同样停留在 ExStart 状态，并不断重传 DD 报文。

3. 技术细节总结表

报文/字段作用备注
I 位 (Init)为 1 表示这是协商主从的第一包仅在 ExStart 出现
M 位 (More)为 1 表示后面还有 DD 报文用于分片传输大型 LSDB 摘要
MS 位 (Master/Slave)为 1 代表自己想当 Master选举完成后，Slave 需将此位置 0
MTU 字段携带发送接口的 MTU 值华为默认为 0，开启 mtu-enable后生效

4. 故障排查建议

如果你在现网中发现 OSPF 卡在 ExStart ，请按以下步骤核查：

  • 检查两端物理接口 MTU 是否一致（尤其是二层专线环境）。
  • 检查是否一端开启了 ospf mtu-enable 而另一端未开启或 MTU 较小。
  • 确认 Router ID 是否冲突（冲突会导致主从选举陷入死循环）。

如果 Hello 报文中的关键参数不一致，邻居关系通常会停留在 Down 状态，或者在特定情况下表现为 Init 状态。

我们需要从 RFC 2328 第 10.5 节（Receiving Hello Packets） 的报文验证机制来深度剖析：

hello报文不一致会停留在哪个阶段?

1. 核心结论：大多停留在 Down 状态

根据 OSPF 协议原理，当路由器接收到一个 Hello 报文时，会首先进行“ 一致性检查 ”。如果以下任何一个关键字段不匹配，接收端会直接**丢弃（Drop）**该报文，不进行任何状态转换。

  • 停留在 Down 状态的情况：
    • Hello/Dead 间隔不匹配 ：这是最常见的错误。
    • 区域 ID (Area ID) 不一致 ：必须在同一区域。
    • 认证 (Authentication) 失败 ：包括认证类型或密钥不匹配。
    • 特殊区域标识 (Options 字段中的 E/N 位) ：例如一端配置为 Stub，另一端为普通区域。
    • 子网掩码 (Network Mask) 不一致 ： 仅限广播型和 NBMA 网络 。在点对点（P2P）链路上，掩码不一致通常不会阻止邻居建立。

技术原理 ：由于报文被丢弃，本地路由器根本不认为收到了有效的 Hello，因此状态机保持在 Down 。

2. 特殊表现：Init 状态

在某些特定的配置不一致下，你会看到一端显示 Init ，而另一端显示 Down （或没有任何显示）：

  • 单向可达性问题 ： 如果路由器 A 发出的 Hello 能到达 B，但 B 发出的 Hello 被 A 侧的 ACL 拦截或因为 A 侧配置了 passive-interface。
  • 结果 ：B 收到 A 的报文，由于 A 的报文里没有 B 的 Router ID，B 进入 Init 状态。而 A 没有收到任何有效报文，保持在 Down 。
  • Router ID 冲突 ： 如果两台直连路由器的 Router ID 相同，它们会收到对方的 Hello 报文。但在处理时，路由器会发现报文中的 Router ID 是自己，从而认为这可能是环路，导致无法进入 2-Way 。

3. HCIE 专家排障对照表

为了方便你在工程中快速定位，可以参考下表：

不一致的参数状态表现 (Local / Remote)权威解释 (RFC 2328)
Hello/Dead TimerDown / Down报文验证失败，直接丢弃。
Area IDDown / Down必须完全匹配才能建立邻接。
Subnet MaskDown / Down (MA网络)MA网络必须掩码一致以确保 ARP/DR 正常。
MTUExStart/Exchange**注意！**MTU 不在 Hello 中检查，是在 DD 报文交换时检查。
AuthenticationDown / Down安全机制要求在状态机启动前验证。

4. 延伸思考：为什么 MTU 不一致不停留在 Down？

这是很多考生的误区。 MTU 并不包含在 Hello 报文中 ，而是携带在 DD (Database Description) 报文中。因此，Hello 报文的一致性检查无法发现 MTU 问题，邻居会顺利到达 ExStart 状态。只有当双方开始交互 DD 报文并检查 Interface MTU 字段时（如果开启了 ospf mtu-enable），才会发现不匹配并卡在那里。