摘要

  • RFC 1513 为 Token Ring 扩展 RMON。dropEvents 记录探针因资源不足而丢包这种状态被发现了多少次,不是探针究竟漏过多少帧。
  • 规范还提醒:软错误报告可能采用可靠投递,混杂模式探针会把同一个底层错误记两次。报告者、上游邻居、站点次序和采样区间都是数字的语境。
  • 监测值、损失推断、责任归因、控制授权和运行结果必须分别取证。后来的 RMON-2 用独立对象表达精确丢帧量,正说明两类计数不能互换。

数字准确,问题却问错了

RFC 1271 把远程探针放到共享网段上,让它长期收集统计、历史、主机、通信矩阵、过滤、抓包和事件。管理站不必搬走所有原始帧,就能查询一组紧凑对象。不过,其中一部分链路层视图按 Ethernet 定义。

1993 年 9 月的 RFC 1513 补上 IEEE 802.5 Token Ring 所需对象,并增加环站、站点次序、站点配置和源路由统计。最值得保留的历史,不在 Token Ring 与 Ethernet 谁胜谁负,而在一段极短的计数器说明。

tokenRingMLStatsDropEvents 在探针因资源不足而丢弃包时增加。规范紧接着说:这个数不一定是丢弃包的数量,它只是这种条件被探测到的次数。

一次资源告急可能漏一帧,也可能遮住一串突发流量。两次告急的持续时间和遗漏规模也可能完全不同。探针可以精确知道自己两次进入“跟不上”的状态,却无法从状态次数倒推出未处理对象总量。

因此,计数器没有说谎。真正越界的是把“事件次数”读成“丢帧数量”的解释。

观察者也会成为故障现场

远程监测之所以便宜,是因为探针在本地过滤、分类和压缩。它的处理器、缓冲区和表项都有限。资源不足时,数字同时描述两件事:网络上仍有流量抵达,观察者却失去完整可见性。

RFC 1513 在 MAC 层即时统计、混杂统计以及按区间保存的历史表里重复这套语义。比较两个值时,必须知道数据来自哪张表、哪个接口、哪一控制行、哪位 owner、什么状态、何时启用、覆盖哪个采样区间。探针重启、控制行重建、计数器回绕或数据源变更,都会让裸值制造一条假的连续曲线。

RFC 4502 后来另设 DroppedFrames 对象,并明确称其为被集合精确丢弃的帧数,特意写出“不同于 dropEvents”。这不是改名字,而是新增一份更强的测量承诺。

可靠送达可能带来两份同样的报告

RFC 1513 还记录了另一种失真来源。Token Ring 的软错误报告包可能采用可靠投递;探针若以混杂方式监听,某些错误可能被意外报告两次。

报告送达得更可靠,不等于每次到达都对应一个新错误。两份包可能是一个底层事件的两次传递。要判断重复,需要报告站点、错误类型、时间、捕获位置以及可复核的去重规则。

规范只证明这种重复具有协议上的可能性。它没有证明任何具名产品真的重计,也没有证明某次告警必然虚高。反过来,零计数也不证明零错误:探针可能缺少容量,某些帧可能不属于该对象的人口,或者计数代次已经改变。

报告者、邻居和原因不是同一个角色

Token Ring 的环形关系进入了错误记账规则。Address Copied 错误会增加报告站点最近上游邻居的条目;线路和突发错误会增加报告站点及其上游邻居;内部和中止错误只增加报告站点。

这些规则便于把证据放进调查所需的格子,却不自动证明物理责任。表中出现某站,可能因为它发出报告、与报告者相邻,或者分类规则要求把数记到它名下。

Ring Station Order Group 给出被监测环上站点的次序,帮助确认“上游邻居”是谁。但次序表只是一张投影:它不证明错误发生时拓扑未变,也不证明每个站点都被看到,更不证明某帧最后送达。

仪表盘若把某站名和红色数字并排,很容易把记账关系变成因果判决。RFC 1513 的细节反而要求保留四层:谁报告、谁相邻、数字记到哪里、真正什么坏了。

“好帧”与“错误事件”来自不同总体

规范定义了 good frame,并让一部分包数、字节数只统计符合链路层条件的帧。错误计数来自错误报告包;dropEvents 来自探针资源不足。三种对象的总体不同。

若拿资源不足事件作分子、好帧作分母,算出的不是丢包率。若一份错误报告可能重复,其数量不能直接变成事故数量。若探针在分类前已经漏帧,后面的类别总和也无法复原未见内容。

这不是一句空泛的“遥测都有不确定性”。恰恰相反:每个对象可以对自己的狭窄定义非常准确。风险出在分析者替它换了一道更大的问题。

可写对象并不授予行动权

RFC 1513 不只提供观察。Ring Station Configuration Group 允许主动移除某站或向其下载配置信息。测量面与控制面由此出现在同一份 MIB。

可是文档在前面已明确:对象的 access level 只说明读写在协议上是否有意义,与行政授权策略相互独立。read-write 不是授权书。

这道边界能阻止错误自动化。dropEvents 上升也许先说明探针自身饱和;站点错误数也许来自邻居记账规则;软错误报告也许重复。任何一项都不足以单独支持把站点踢出环。

主动操作需要另一条回执链:请求者身份、授权决定、目标站点、操作前次序、命令、响应、配置状态和操作后的网络效果。触发调查的对象不能同时充当行动合理且成功的证明。

源路由统计同样只是一种局部观察。它从帧里可选的路由信息推导利用率分类;没有路由字段的帧不提供同类证据,一处环上的观察也不等于端到端路径。

来源能证明到哪里

RFC Editor 信息页和 Datatracker 证明文档、日期、作者、谱系与今天的 Historic 状态。RFC 1271、1757、2021、2819、3577 与 4502 展示 RMON 家族如何扩展和改写。

它们不证明任何具名部署、真实丢帧、厂商缺陷、事故或修复效果。Historic 不是事故报告;后来因独立互操作证据不足而弃用某些 Token Ring RMON-2 增补,也不等于 RFC 1513 在某个网络失败。

Heng Lu 的 Running-Code Primacy 要求用实际执行与结果检验共同规范;Minimum Initial Specification 要求共同层只承担最小必要含义,把本地能力与选择留在明处;On Reality Layers 则提醒数字只是现实投影,不能借来现实本身的权威。

所以,42 可以严格证明探针识别过 42 次资源告急。没有其他回执,它不能升级为 42 个丢失帧、42 次网络故障,更不能升级为 42 份处罚站点的授权。

来源

  1. RFC 1513 信息页
  2. RFC 1513 正文
  3. RFC 1513 Datatracker
  4. RFC 1271 信息页
  5. RFC 1271 正文
  6. RFC 1757 信息页
  7. RFC 1757 正文
  8. RFC 2021 信息页
  9. RFC 2021 正文
  10. RFC 2819 信息页
  11. RFC 2819 正文
  12. RFC 3577 信息页
  13. RFC 3577 正文
  14. RFC 4502 信息页
  15. RFC 4502 正文
  16. Running-Code Primacy
  17. Minimum Initial Specification
  18. On Reality Layers