在 OSPF 这种基于链路状态（Link-State）的协议中，LSDB（链路状态数据库）的一致性是算法运行的基础。一旦不同路由器的 LSDB 同步出现偏差，SPF 计算就会得出完全不同的路径，进而导致环路或流量黑洞。

为了保证全网 LSDB 的 强一致性 ，OSPF 设计了 MaxAge（生存时间） 、Checksum（校验和） 与 LSAck（确认机制） 三位一体的保障机制。

1. Checksum：确保 LSA “内容”的完整性

Checksum（校验和）用于检测 LSA 在传输或存储过程中是否发生了位错误。

  • 计算范围： Checksum 涵盖了除了 LS Age 字段以外的所有 LSA 头部及数据内容（因为 LS Age 在传输过程中是动态变化的，不能参与校验）。
  • 周期性校验： 路由器每隔 10 分钟 会对 LSDB 中的每一条 LSA 进行一次 Checksum 验证。
  • 触发同步： 如果路由器发现某条 LSA 的校验和失效，它会立即从 LSDB 中删除该 LSA，并向邻居请求最新的 LSA 副本。

2. MaxAge 与 LS Refresh：确保 LSA 的“时效性”

OSPF 并不是一个完全触发更新的协议，它具备周期性刷新机制来防止数据库条目过时或僵死。

  • LS Age（生存时间）： * LSA 被产生时，LS Age 为 0。
    • 在 LSDB 中存储时，该值每秒加 1；在链路上传输时，会增加一个 InfTransDelay。
  • LSRefreshTime (1800s/30min)： LSA 的始发路由器每 30 分钟会重新生成一个新的序列号（Sequence Number）并泛洪该 LSA。
  • MaxAge (3600s/60min)： * 如果一条 LSA 的 LS Age 达到了 3600s 且没有收到刷新报文，说明该 LSA 已失效，路由器会将其从 LSDB 中剔除。
    • 强制删除机制： 当 ABR/ASBR 想要主动删除一条 LSA 时（例如接口断开），它会故意将该 LSA 的 LS Age 设置为 MaxAge 并泛洪。邻居收到后，会通过这个特殊的 Age 值立即从数据库中清除该条目，而不是等待其自然超时。

3. LSAck：确保 LSA “传递”的可靠性

由于 OSPF 直接封装在 IP 报文（协议号 89）之上，没有 TCP 这种可靠传输层支持，因此必须在应用层实现自己的确认机制。

  • 显式确认 (Explicit Acknowledgment)： 路由器接收到 LSU (Link State Update) 后，会返回一个 LSAck 报文，其中包含接收到的 LSA 头部信息，告知发送方：“我已经收到了这部分更新”。
  • 隐式确认 (Implicit Acknowledgment)： 在多路访问网络中，如果 DR 发送了一个更新，收到的路由器反馈了相同的 LSA 信息给 DR（通过 LSU），这也可以被视为一种确认。
  • 重传定时器 (RxmtInterval)： 如果发送方在指定时间内（默认 5s）没有收到 LSAck，会重新发送 LSU 报文，直到收到确认为止。

4. 三者协同：LSDB 同步的逻辑链路

我们可以通过一个 LSA 更新的生命周期来串联这三个机制：

  1. 触发： 链路状态变化，产生新 LSA（LS Age=0, Seq++, Checksum 已计算）。
  2. 传输： 通过 LSU 泛洪，接收方收到后校验 Checksum 。
    • 若校验失败：丢弃，不返回确认。
    • 若校验成功：对比序列号。若序列号更新，则更新 LSDB 并返回 LSAck 。
  3. 存储： LSA 驻留在 LSDB 中，LS Age 递增。
    • 若达到 1800s：始发者执行 LS Refresh 。
    • 若达到 3600s：该条目被认定为 MaxAge ，从数据库清除并全网泛洪。

5. HCIE 深度考点：序列号与校验和的溢出处理

作为专家，你可能还会遇到两种极端情况：

  • 序列号回绕： OSPF 采用的是线性序列号空间（$0x80000001$ 到 $0x7FFFFFFF$）。如果序列号达到了最大值，始发路由器会将该 LSA 置为 MaxAge 提前让其失效，然后重新从起始值开始计数。
  • Checksum 错误攻击： 如果由于内存损坏或恶意攻击导致 LSA 头部 Checksum 错误，路由器会通过泛洪一条 MaxAge LSA 来清除这种错误的拓扑信息，触发全网重新同步。

这一套机制保证了 OSPF 在大规模、不稳定网络环境下的鲁棒性。