摘要

  • 传统点到点 IS-IS 在听到对端 Hello 后即可把对端视为可达，却未必知道对端能否听到回程。RFC 5303 用 Down、Initializing、Up 三种独立状态，把单向观察和双向确认分开。
  • Neighbor System ID 与四字节 Extended Local Circuit ID 可将回执绑定到正确系统和正确电路。但三向 Up 只证明 IIH 往返，不证明 LSDB 已同步、FIB 已安装、数据包已双向通过或服务已交付。

两条并行链路，如何把单向故障藏起来

先看最反直觉的故障。两个系统之间有两条并行链路，其中一条只坏了一个方向。一个系统能发现，另一个系统不能。若只有这一条链路，单边通告通常会使 SPF 忽略它；但因为另一条链路仍在，SPF 仍然可以算出两台系统之间的路径。没有感知故障的一端，可能继续把流量交给已经失效的方向。

这时，“整体仍可达”是真话，“该成员可用”却是假话。冗余没有制造故障，却掩盖了证据缺口。用整网连通性替每个成员背书，就会在流量哈希、容量变化或另一条链路受压时才发现问题。

RFC 5303 还描述了另外两种已知情形。第一种发生在链路恢复或系统重启之后。如果触发数据库同步的 CSNP 丢失，而且该链路是网络中的唯一割集，两侧链路状态数据库可能要等完整 LSP 刷新周期才重新同步，最长可达十八小时。Hello 已经成功，不代表同步已经成功。

第三种不是简单的断线。有些物理层可以改变端点之间的连接关系，却不产生 link-layer-down。于是某系统可能收到本来发给另一系统、或同一系统另一条链路的报文，并把它错误归入旧邻接。报文确实到达了；“从正确电路到达”仍然没有证据。

RFC 5303 是 2008 年发布的 Standards Track 文档，是 RFC 3373 的小幅修订，用于把原来的信息性机制推进到标准轨道。它不是今天某个厂商或网络的故障报告。本文只使用它界定证据边界，不推断当前部署状况。

三向状态是另一台状态机

RFC 5303 定义了 Point-to-Point Three-Way Adjacency 选项。三向状态为 Down 时，表示本电路尚未收到携带该选项的 IIH；进入 Initializing，表示已经收到，但本端仍不知道对端是否收到自己的 IIH；成为 Up，才表示本端知道对端正在接收自己的 IIH。

关键之处在于，这个三向状态不等于 ISO 10589 的邻接状态。两者可以同时存在。收到 ISH 可能推动 ISO 邻接变化，却不会让三向状态脱离 Down；三向状态必须等到携带选项的 IIH。若监控系统把两个状态压成一个“邻接已建立”，它正好抹去了标准新增的信息。

状态转换表还保存了双方视图不一致时的含义。例如，本端为 Up、收到对端 Down 时，会回到初始化；本端为 Down、却收到对端 Up 时，可删除邻接并记录“邻居重启”。这些组合不是需要平均掉的噪声，而是故障发生顺序的证据。

即便如此，Up 的语义仍很窄：按该机制，对端能收到本端 IIH。它没有说明后续 CSNP 是否到达，没有说明每条 LSP 是否一致，没有说明路由是否进入 FIB，也没有说明数据面或应用返回。把 Up 写进哪一列，决定了组织以后会误信什么。

回程报文还要说清自己来自哪条电路

确认双向可听，仍不足以解决接错线的问题。新选项可携带 Neighbor System ID 与 Neighbor Extended Local Circuit ID。字段存在时，接收方必须与自己的系统 ID 和扩展电路 ID 比较；任一不符，PDU 就被丢弃，不再处理。

为什么需要新的电路标识？传统表示存在隐含的 256 接口问题，虽然真正的 LAN 限制更具体。点到点实现常常复用 circuit ID，因为旧值主要在 IIH 中用于识别远端身份变化。复用削弱了这项保护：链路被移到另一个恰好使用同一小编号的接口时，旧关系可能看起来从未中断。

Extended Local Circuit ID 有四个字节，在电路创建时分配，并且必须在该中间系统的全部电路中唯一。它不必与旧 Local Circuit ID 有关。这不是单纯扩大容量，而是让“我确认的是哪条电路”拥有足够稳定的名字。

但身份绑定有强弱之分。支持该机制的系统必须放入三向状态字段，其他字段则是 SHOULD。如果 Neighbor System ID 或邻居扩展电路 ID 不存在，流程仍可继续。于是，“观察到三向 Up”和“系统及电路身份均已匹配”是两种不同结论，不应共用同一审计标签。

向后兼容，等于公开接受一份较弱回执

RFC 5303 刻意保持兼容。不理解新选项的系统会忽略它，也不会在自己的 IIH 中携带它。支持新机制的一端若收到不含选项的 IIH，就假设链路双向正常，继续执行旧流程。这样可以渐进升级，不会因一个邻居较旧而立刻中断关系。

代价同样明确：协议允许在没有双向回执时继续。运维界面如果只显示“本端支持 RFC 5303”，就会把本端能力错当成会话证据。真正需要记录的是：是否发送选项、对端是否回送、三向状态是什么、身份字段是否存在并匹配、会话是否回落到旧假设。兼容不是失败，但它是一项应有范围、责任人和退出日期的证据例外。

认证也不能替这些层次签字。RFC 5303 指向 IS-IS 安全机制；RFC 5304 与 RFC 5310 讨论密码认证。认证可以证明消息来自持有被接受密钥的一方，并保护完整性，但它不自动证明物理接线正确、LSDB 已收敛或数据已送达。BFD 则定义另一类快速双向转发检测。不同机制存在，正因为它们观察的是不同事实。

本文结论的边界

本文不声称某个平台当前缺少该选项，不声称某张网正遭遇单向故障，也不以历史 RFC 推断现实故障率。验证现网需要版本、配置、IIH 捕获、身份字段、数据库对比、FIB 与数据面观测。

部署三向机制也不会消除全部不确定性。旧邻居会触发兼容回落，推荐字段可能缺席，密钥策略另有生命周期，数据库和转发验证发生在邻接建立之后。另一方面，也不能因为三向机制不证明服务结果，就否定它在定位单向听见和错误电路绑定方面的价值。

最稳妥的结论只有三句：听见对端，不等于对端听见我；对端听见我，不等于回执属于正确电路；正确电路完成握手，也不等于后续数据库和业务已经完成。

来源