摘要

  • 在 RFC 2024 中，目录行表达的是 DLSw 节点认为某个 MAC 地址或 NetBIOS 名称可以从哪里抵达；它不是“终端电路已接通”的证明。
  • 传输连接、电路、节拍额度和断连字段各自回答更窄的问题，事故判断必须保留这些证据边界。

“这个资源通不通？”看起来只需要一个答案。RFC 2024 却把答案拆进多张表：目录负责指出位置，传输表记录 DLSw 对等端是否完成能力交换，电路表追踪终端之间的具体路径，流控字段则说明发送方还获准发送多少条带节拍的 SSP 消息。任何一项都不能代替另一项。

这种克制正是 DLSw 运维的要害。把一个前提显示成绿色，并不代表业务链路已经走完。

目录行记录的是位置判断

MAC 与 NetBIOS 目录把资源指向一个位置。这个指针可能落到本地接口、已配置的传输连接、正在运行的传输连接、空引用，或者厂商自有的表。状态只有未知、可达和不可达，但 RFC 2024 的措辞很谨慎：它描述的是 DLSw 当时“相信”该资源能否经由那个位置访问。

静态配置示例把限制讲得更清楚。一个条目起初可以是未知；同一远端资源可以列在多个伙伴之后；候选顺序没有保证；同样具体的静态与动态信息发生冲突时，选择甚至可以由实现决定。搜索失败后保留“不可达”，也可能只是为了避免立即重复搜索。

所以，目录命中缩小了寻找范围。它没有证明目标伙伴已经连接，没有证明电路建立已经开始，更没有证明终端此刻会响应。

传输连接有自己的时间线

传输运行表区分连接中、初始能力交换、已连接、静默中、断开中和已断开等状态。这里的“已连接”只表示双方已确定能力，可以处理建立电路所需的消息；它不是终端会话成功的缩写。

配置与运行之间的链接也会老化。dlswTConnOperConfigIndex 指向治理该连接的配置行，但配置行删除后，这个值会变成零。连接建立后若再修改配置，现有连接仍可能沿用先前协商的条件。RFC 2024 因而要求把连接时间与配置最后修改时间一起看。

实现还可以在断连后保留运行行，用来保存统计与故障原因，而且没有统一的保留期限。伙伴能力字段记录的是收到的信息，也可能继续出现在这条历史记录里。字段仍然可读，不等于伙伴仍然在线。

发现资源以后，电路才开始建立

RFC 2024 把电路启动分成两个阶段：先由探索报文定位 MAC 地址或 NetBIOS 名称，然后才进入电路建立。电路表是在第二阶段开始时才出现一行，而不是目录第一次找到位置时就出现。

电路拥有自己的一长串状态。唯一可写的是 disconnectPending；MIB 没有提供“重新建立电路”的管理命令，因为建立动作由终端驱动。断连原因与指向底层 LLC 或 SDLC MIB 的引用可以缩小调查范围，部分流量统计也必须顺着这些引用去找。它们是同一条证据链上的线索，不是自动生成的根因报告。

节拍字段同样只说明一件事：一端在必须停下等待之前，目前还被授权发送多少条带节拍的 SSP 消息。不使用节拍时，数值也可能为零。当前窗口或最大窗口既不是送达回执，也不能证明应用工作已经完成。

通知抓住的是一次跃迁

传输或电路进入已连接状态时，代理可以发出相应 trap；但通知可以配置，也可以关闭。收到通知，证明某个本地代理报告过一次状态跃迁，而且通知送达了。它不能证明状态持续存在，不能证明另一端看到同样的状态，也不能排除随后发生断连。反过来，没有 trap 也不能证明跃迁从未发生。

断连时间、断连原因和“是否存在活动电路”能让故障描述更精确。最后一项只说明当时可能有终端用户受到影响，并不统计用户数，也不证明业务损失。后来的 RFC 2166 为 RFC 1795 增加了较宽泛的 HALT 原因，与终端发起断开、DLC 错误、电路协议错误和操作员动作等分类相近。旧伙伴可能不携带原因，厂商细节也可能不同。线索变得更具体，却仍不是最终根因。

完整画面可能分散在两端

RFC 2024 明说，完整视图可能需要从多个协作的 DLSw 节点取数。为了减少重复，有些字段被定义为从伙伴收到的信息。协议也没有办法把伙伴的受管传输地址可靠地对应到其管理协议地址。

因此，每一行都是有边界的本地证词。Lu Heng 关于“记录与其所描述的现实并非同一层”的区分，为今天阅读这套 MIB 提供了有用视角：记录可以准确，却仍不是完整运行状态。这是当代分析框架，不是对 RFC 作者意图的推断。

正确做法不是怀疑所有表，而是保留连接它们的索引、时间和本地语境。目录支持位置判断，传输表支持伙伴连接与协商时点，电路表支持终端路径，底层 MIB 提供局部链路证据。跨两端比对时，它们能解释服务；被压成一盏绿灯时，它们只会掩盖问题。

来源