Summary

  • RFC 1574 于 1994 年 2 月提出 OSI/CLNP 网络的最低排障工具组合：回声探测、利用报文 Lifetime 的路径追踪，以及从主机或路由器导出路由表。
  • 探测包若设置了错误报告标志，不认识新回声类型的 CLNP 节点也可返回错误。这个错误能指出一个回应的节点，不能代替终点已通的证据。

值班员接到故障电话，先发一个探测包。屏幕上冒出错误：对方不支持这个新回声请求。按普通仪表盘的逻辑，这是红灯；按排障的逻辑，至少有一台设备收到了包，还把抱怨送了回来。Susan Hares 和 Cathy Wittbrodt 在 1994 年的 RFC 里给这种区别留出了位置。他们指出，OSI 网络层的排障工具稀少；即使有工具，不同实现之间也常常互不兼容。

第一件工具是 CLNP 回声。RFC 1575 定义了十六进制 1E 请求和 1F 回答两个选择值；RFC 1574 要求请求方打开错误报告标志。懂 CLNP、却不懂新回声类型的旧节点，应尝试送回错误包。正常回声说明对方处理了新请求；错误包说明某个节点听见了它，随后指出无法处理。最糟的界面设计，是把两者和彻底沉默都压成同一盏红灯。

原文因此要求 Ping 工具显示每个包的往返时间、多次探测的平均值与最小最大值，还要把收到的错误代码交给用户。一次故障里，代码比颜色更值钱。错误从第一跳回来，排查方向与错误从远端回来完全不同；把来源藏掉，值班员就只能在整段网络里乱猜。

第二件工具把路径拆成一跳一跳。CLNP 报文里的 Lifetime 类似 IP 的 TTL。设为 1，第一跳因寿命耗尽而回错误；设为 2，下一跳可能回应；逐次加大，便看到沿途的应答。A0、A1 是两种寿命耗尽情形，B0 是不支持选项，80、81 分别指向不可达或未知的目的地。它们不是装饰性的错误号码：代码换了，下一步要检查的设备也可能换。

还有一处容易让人被“成功”骗过。探测包可以请求经过某个中途节点，即部分源路由。ISO 8473 允许不支持该选项的节点照常转发，就像从未收到这项要求。包最终抵达，并不能证明它经过了指定的中途站。RFC 1574 让追踪工具报告源路由地址未知、路径不可接受等错误。要查的是一条指定路线，终点亮灯远远不够。

第三件工具是把路由器心里的地图拿出来。RFC 1574 要求提供 OSI 服务的主机与路由器，能通过带外办法导出各自的路由表。表项可能来自 ES-IS、IS-IS、IDRP、静态配置或别处。文档建议 show osi routes 一类命令，也提到 SNMP、CMIP；当时的 CLNS MIB 尚不能提供全部所需信息。路由表说的是本机准备怎样转发，探测结果说的是哪些节点真的回了话，两份材料需要放在一起读。

这份信息性 RFC 规定工具行为，并未提供某次真实故障的测量。要判断某个实现是否兑现要求，还缺带日期的回声记录、逐跳追踪和路由表输出。作者留下的锋利之处在于：失败的请求也可能产生有价值的回复。前提是工具把那份回复原样呈现，而不是替操作员把它涂成一片红。