摘要

  • RFC 1515 为以太网 MAU 分别定义了 jabber 当前状态、进入 jabber 状态的累计次数，以及用于唤起管理端注意的 trap。
  • 相邻 trap 必须至少间隔五秒。告警通道因此有意受限，收到几次告警不能直接当成发生了几次状态转换。
  • 后来读到 noJabber 不会抹掉此前计数；计数增加也不能证明异常仍在持续。对象身份、适用范围与计数时期必须一同保存。

五秒窗口里的三种答案

设想一个 MAU 进入 jabber 状态，恢复正常，四秒后再次进入。这个场景只是说明规范逻辑，并不是一起真实事故。状态对象可以跟随最新情况，进入次数可以加二，但告警规则不允许两条 jabber trap 相隔不足五秒。

只接告警的控制台可能只看到一次。事后轮询可能得到 noJabber。前后读取计数器则可能发现两次进入。三者并不互相否定，它们回答的是不同问题。

RFC 1515 最耐看的地方正在这里：它没有为了抑制告警风暴，就假装被压缩的告警流仍是一份完整历史。即时信号、当前状态、累计证据被设计成三张边界不同的收据。

先确定是哪一个物理连接

RFC 1515 于 1993 年 9 月发布，为 IEEE 802.3 的 Medium Attachment Unit 定义管理对象。MAU 位于以太网式接口或中继器端口与介质之间。规范分别为中继器连接的 MAU 与接口连接的 MAU 建立基本组。

在任何告警之前，对象身份先要明确。中继器一侧的行由组索引、端口索引与 MAU 索引定位；接口一侧则与 MIB-II 的 ifIndex 对齐。若采集器只留下“jabber=4”，却删掉这些坐标，后来就无法知道是哪一个连接发生变化。

规范也没有把所有物理层观察压成“端口健康”。管理状态、介质可用性与 jabber 各有对象。某些介质上，介质不可用可能表示链路丢失、低光、没有回环、远端故障或无效信号；这些语义依 MAU 类型而变，不能自动成为 jabber 的原因说明。

状态只回答此刻

中继器与接口 MAU 的 jabber 状态都有四个值：other、unknown、noJabber、jabbering。初始化期间无法知道真实状态时，unknown 是合法答案；noJabber 是正常状态；jabbering 表示该 MAU 此刻处于 jabber 状态。

这套词汇刻意很窄。它没有指出是哪块板卡、哪条线或哪台发射器坏了，也没有报告持续多久、丢了多少帧、影响了谁，更没有证明运维人员已经收到告警或完成修复。

适用边界同样重要。对 AUI 类型，代理必须返回 other，进入次数也恒为零。所以，一个整齐的零可能只是对象按规定不适用，不能被扩写成“物理层不存在任何故障”。

计数器记住进入动作

rpMauJabberingStateEnters 与 ifMauJabberingStateEnters 计算的是进入 jabbering 的次数。一次持续很久的异常可能只加一，数次短促异常可能加多次。它不计秒数、帧数、字节数、用户数，也不计发出了多少告警。

这个数还必须带着观测时期。2003 年的后继规范 RFC 3636 明说，管理系统重新初始化等情况会让计数出现不连续，并让接口侧计数关联 ifCounterDiscontinuityTime。只保存最新整数，会把重启后的归零误写成改善，或把两个时期拼成一条不存在的历史。

计数器也不能替代状态。若计数增加而后来状态正常，严谨说法是：“这个观测时期内发生过进入动作；本次轮询没有看见它仍在持续。”历史与现在可以朝不同方向为真。

Trap 天生不是完整账本

RFC 1515 为中继器 MAU 与接口 MAU 各定义一种 jabber trap，并携带相应的当前状态。MAU 进入 jabber 状态时应发送 trap，但连续 trap 必须限流，至少相隔五秒。

这条规则保护管理通道不被突发通知淹没，同时也划出证据上限。如果保护窗口内发生多次进入动作，收到的 trap 数就不能等同于状态转换数。“记录里有一条告警”只支持“代理发出并在现有记录中观察到一条通知”，无权推出“底层只发生了一次”。

RFC 1157 把 SNMPv1 Trap-PDU 与请求/响应 PDU 分开定义，其中含有生成方、代理地址、trap 标识、从网络实体最近一次初始化起计算的时间戳，以及变量绑定。RFC 1215 又给出 RFC 1515 所用的 TRAP-TYPE 约定。这些字段让通知可以解释，却没有把它变成端到端投递证明或完整事故日志。

速度提高，边界仍然留下

这不是只适用于 10 Mb/s 年代的偶然安排。RFC 2239 以超集替代 RFC 1515，加入 100 Mb/s、自动协商与插孔管理；RFC 2668 再次扩展；RFC 3636 又加入 10 Gb/s 管理，并废止 RFC 2668 与 RFC 1515。

在这条谱系里，状态、进入次数与五秒告警间隔一直存在。后来规范进一步说明，若干更高速的 MAU 类型在这些 jabber 进入计数上应返回零。标准演进增加了类型与能力，却没有把老对象膨胀成包打天下的故障裁决。

这也体现了运行代码的克制。共同层只规定代理与管理端必须能交换的稳定语义；轮询频率、保存期限、升级阈值与处置政策仍留给本地实现和运维者。

不替缺失证据补写故事

一份可复查的记录至少应保存 MAU 身份与类型、当前状态、进入计数、计数时期、通知内的时间戳、接收时间以及轮询间隔。Trap 是发送代理的一次观察，不是最终收件证明；介质可用性与接口层证据也应并列保存，不能被倒填成 jabber 的根因。

于是文字会更克制：“一个五秒窗口里计数增加二，记录到一条 trap”是可证的；“端口坏了两次”未必可证。“当前状态正常”是可证的；“设备已修复”还需要修复定义与另一张收据。

Lu Heng 关于运行代码优先、最小初始规范与现实层的三篇文章，为这种读法提供了编辑纪律：标准标签只有贴着实现与可执行观察时才有意义。告警可以召唤行动，却不能统治自己从未保存的事实。

来源与证据边界

技术叙述依据 RFC Editor 的 RFC 1515 记录、RFC 1515、RFC 1157、RFC 1215、RFC 2239、RFC 2668 与 RFC 3636。它们确立对象语义、通知结构和标准演进；三篇 Lu Heng 文章提供层次、可验证性与本地决策的解释框架。

这些资料不能证明今天某项产品的符合度、部署比例、具体事故、trap 投递率、丢帧量、硬件损坏或修复结果。开头的两次状态转换只是对限流规则的逻辑演示，不是真实事件报道。