摘要

  • RFC 1461 在 1993 年 5 月规定了 X.25 上多协议通信的 SNMP 管理对象。向外找不到 X.121 对端、向内认不出 X.121 来电者，是两组不同的失败。
  • 两组对象各有计数器、最后失败的地址和以设备运行时间为基准的时刻。即便无法准确判定该把失败记在哪个接口下，RFC 仍要求先把它记下来。

网络设备最会制造一种错觉：接口亮着，问题就该出在线路深处。Mark Throop 写的 RFC 1461 把视线往前挪了一步。按照 RFC 1356，IP 等网络层协议可以封装后走 X.25；可发起 X.25 呼叫时，设备需要的是对端 X.121 地址。包的 IP 目的地址不会自己变成电话号码。

管理表的划分很直白。第一张表只列真正承载多协议流量的 X.25 接口；有 X.25 接口，却不用来运送这类流量，就不该出现在这里。第二张表列对端、它的 X.121 地址、该走哪个接口以及呼叫参数。第三张表列对端接受哪些封装形式。线路、对端和协议能力，必须逐项成立。只看电路状态，相当于查到电话线有电，却没翻通讯录。

向外发送时，如果封装地址既不能从对端表、也不能经算法找到 X.121 号码，失败计数就增加。RFC 还保存最近一次失败的封装地址。IP 地址在这里占五个八位组：开头的 0xCC 标明封装类型，后面四个才是 IP 地址。另一个字段保存最近失败时的 sysUpTime。它标的是设备启动后的相对时间，不能直接冒充某年某月某日的事故时间。

来电方向另算。设备接到 X.25 呼叫，可能无法把呼叫者的 X.121 地址识别成封装地址；这时增加另一只计数器，留下最后失败的 X.121 号码和相对时间。Q 位错误导致的连接关闭还有独立记录。三个症状放在同一个“X.25 故障”标签里，会把排查线索主动扔掉。

最值得注意的是 RFC 对记录精度的坦白：向外查找失败时，如果代理程序不知道该归给哪一个分组层接口，就选第一项可能的接口，也要把失败算进去。计数可用，不代表接口归因一定准确。此前的 RFC 1382 管电路与呼叫参数；RFC 1461 管那些电路背后要拨给谁、能用什么封装。这份规范没有给出实际部署的故障率，却准确指出了故障可能发生在哪一步。