摘要

  • RFC 2358 在保留统一以太网接口身份的同时，为 100 Mb/s 增加符合性要求与符号错误观测，并把专用统计表与通用接口索引对齐。
  • 每个计数器只对定义内事件负责；当前速度、能力、双工、错误、采样时期、故障假设与修复结果都必须分别举证。

速度升级最容易制造一种错觉：只要仪表上的数字更大，旧的认识就仍然完整。Fast Ethernet 证明并非如此。线路快了十倍，信号编码、介质选择、能力声明和错误分类都需要更细的管理语言。1998 年 6 月发布的 RFC 2358 正是在这个位置上工作：它扩展观察面，却没有把观察面包装成自动诊断器。

这份 Standards Track 文档取代 RFC 1650，加入管理 100 Mb/s 以太网接口所需的信息。作者同时明确承认，Ethernet 仍会随着速度、线缆和功能继续变化。标准谱系很快印证了这一点：RFC 2665 在 1999 年加入千兆与全双工管理，随后 RFC 3635 又扩展到 10 Gb/s。因此，RFC 2358 是一个历史截面，不是今天仍应孤立使用的最终 MIB。

它首先稳定了类型身份。无论速率和链路封装如何，以太网式接口都应采用 ethernetCsmacd(6)；fastEther(62) 与 fastEtherFX(69) 不应用来把同一种技术拆成新的类型。实际运行速率放在 ifSpeed，介质与双工信息放在 802.3 MAU MIB 的 ifMauType。统一身份负责“它是什么”，其他对象负责“它此刻怎样运行”。

这种分工挡住了一个直觉错误。100 Mb/s 全双工链路的 ifSpeed 仍应报告 100 Mb/s，而不是把两个方向相加成 200 Mb/s。RFC 2358 要求实现 MAU MIB，正因为它本身没有标准对象告诉应用双工状态。只看到速度、没看到 MAU 证据时，监控系统不能从吞吐量猜出双工，再把猜测写成事实。

能力也不是现状。只要接口具备 100 Mb/s 能力，就必须实现 ether100MbsCompliance，即使当前降速运行。只在百兆下适用的计数器可以不增长。符合性说明设备应当提供什么能力，并不证明这次协商的速率、链路负载、错误率或业务健康。

两套观测通过索引连接。dot3StatsIndex 与相同数值的 ifIndex 指向同一个接口。通用的包、字节、状态可以由此和 Ethernet 专属的碰撞、FCS、符号错误放在同一上下文里。可是一旦设备重启、索引重排或资产映射陈旧，再精确的计数也可能被挂到错误端口上。连接键本身就是证据链的一部分。

RFC 2358 最有时代特征的新对象是 dot3StatsSymbolErrors。当有效载波存在时出现无效数据符号，它才递增；同一载波事件内即使出现多个坏符号，也最多增加一次。因此，一个增量表示“又发生了一次符合定义的载波事件”，不表示一个坏比特、一个坏帧或一次用户可见中断。计数器的名字如果脱离计量单位，很容易比事实说得更多。

碰撞类对象也有严格边界。晚碰撞指发送超过 512 bit-times 后才检测到的碰撞；文档给出的 10 Mb/s 等价时间是 51.2 微秒。过量碰撞统计因碰撞过多而发送失败的帧。延迟发送表示第一次尝试因介质忙而等待，不包含发生碰撞的帧。可选碰撞直方图则按一帧经历的碰撞次数分桶。

这些定义让不同实现有共同语言，却没有自动给出根因。晚碰撞上升可能与拓扑越界或双工失配相容；FCS、对齐和符号错误可能与介质损坏、电气噪声、光模块、接口芯片或驱动有关。MIB 没有指出哪根线、哪一端、哪个配置应负责。相容性只是调查方向，不是归责结论。

dot3StatsInternalMacTransmitErrors 更直接承认了边界。它收集没有被晚碰撞、过量碰撞或载波检测错误统计的内部 MAC 发送失败，而且“精确含义”由实现决定。这是一个经过排除定义的剩余桶。没有厂商与实现上下文，不能把它翻译成统一故障原因。

dot3StatsEtherChipSet 则记录测量来源。它标识负责收集发送、接收与错误指示的芯片，让管理端能够考虑已知芯片异常。它回答“谁产生了这组观测”，不回答“谁造成了故障”。传感器出处提高证词的可解释性，但不会让传感器成为被告。

连错误总数也不能随意相加。一个接收帧同时满足多种错误条件时，会按照 MAC 服务最终呈现给上层的状态，只计入其中一类。图表反映的是分类器决定，不是每个帧所携带全部物理症状的无损清单。

时间是另一项不可缺少的坐标。多数统计是 Counter32；计算增量必须知道采样间隔和不连续时期。重启、接口复位、计数清零或索引变化都可能让简单相减失效。RFC 2358 借助通用 Interfaces MIB 提供相关上下文。一个数值若没有设备、接口、测量者与时期，就不能跨系统成为可靠证据。

主动测试也不是捷径。文档通过当时已废弃的 ifTestTable 描述环回与时域反射测试，但支持是可选的，许多芯片两者都不支持；标准 MIB 甚至不承载 TDR 结果，需要厂商对象。调用、完成、取回、解释、定位和修复后复测，分别是不同记录。

安全章节延续了这种分层。模块没有 read-write 或 read-create 对象，正确实现不会让入侵者用 SNMP SET 直接改写它们；但只读数据仍可能敏感。芯片组身份会泄露设备厂商信息。SNMPv1 本身并不安全，即使底层网络由 IPsec 保护，也没有自动回答安全网络里的哪个主体有 GET 权限。RFC 建议采用 SNMPv3 的用户安全与视图访问控制。

于是，一次可信调查至少要保留：设备与端口身份；索引连接；采样与不连续时期；当前速度；百兆能力；MAU 与双工；分类计数；芯片与实现；对端观测；故障假设；变更记录；修复后复测。前一行成立，不会让后一行自动成立。