波仔
📡 第二章 彻底理解L2交换机
📄 一句话概括

SNMP 读的是「累计字节数」，不是速率；32 位计数器在千兆下 34 秒就回绕。 这是全章最该记住的一个数字——流量监控出问题，十次有八次是它。

📝 本节和前面几节的关系

上一节讲准入，这一节讲运维。这是日常接触最多的一块。 这一节要算：计数器回绕周期，以及算错会差多少倍。

一、三种管理方式

CLI：命令行。最全，但要人守着。 SNMP：网管软件轮询。能画趋势、能告警。 Syslog：设备主动推日志。故障排查的原始证据。

三者不重复：CLI 做配置、SNMP 做监控、Syslog 做追溯。 只有 CLI 的运维等于「出了问题才上去看」。

二、32 位计数器的坑

SNMP 读的流量是累计字节数，标准 MIB 里的 ifInOctets 是 32 位。最大 4294967295 字节， 到了就回绕到 0。

千兆口每秒 1.25 亿字节，34.4 秒就转一圈。如果你每 5 分钟轮询一次， 两次采样之间计数器已经转过好几圈。

算出来的速率完全是错的，而且错得没有规律——这就是为什么很多流量图看起来「忽高忽低」。

三、三个解法

一、用 64 位计数器：ifHCInOctets／ifHCOutOctets。千兆要跑 4687 年才回绕。这是正解。

二、缩短轮询间隔：至少短于回绕周期。 千兆要 30 秒以内，万兆要 3 秒以内——设备一多根本做不到。

三、判断回绕：这次读数比上次小就按回绕补偿。只能处理「一圈」，转两圈没法补。

顺带记住 SNMP 三个版本：v1 明文、v2c 明文加 community、v3 有认证与加密。 生产网应该用 v3——v2c 的 community 在网络上是明文传的。

四、动手 Demo：六种速率的 32 位计数器回绕周期

这段算 10 Mbps 到 100 Gbps 六种速率下 32 位计数器转一圈要多久， 再用一个具体例子算「5 分钟轮询会差多少倍」。

for bw in (10, 100, 1000, 10000, 25000, 100000):
    per_sec = bw * 1e6 / 8
    wrap = 4294967295.0 / per_sec
    unit = u"%.1f 秒" % wrap if wrap < 120 else u"%.1f 分钟" % (wrap / 60)
    T([u"%d Mbps" % bw, format(int(per_sec), u","), unit], [0, 0, 0])

实跑输出：

--------------------------------------------------------------------
SNMP 的 32 位计数器，1 Gbps 下 34 秒就转一圈
--------------------------------------------------------------------
**这一节是全章最该记住的一个数字。**因为流量监控出问题，十次有八次是这个原因。

**SNMP 读的流量是「累计字节数」，不是「速率」。**标准 MIB 里的 `ifInOctets` 是 32 位无符号整数，
最大 4294967295 字节。

**到了这个数就回绕到 0。**算一下多久到：

  链路速率        每秒字节           回绕周期
  ------------------------------------------------
  10 Mbps         1,250,000          57.3 分钟
  100 Mbps        12,500,000         5.7 分钟
  1000 Mbps       125,000,000        34.4 秒
  10000 Mbps      1,250,000,000      3.4 秒
  25000 Mbps      3,125,000,000      1.4 秒
  100000 Mbps     12,500,000,000     0.3 秒

**千兆口 34.4 秒就转一圈。**如果你每 5 分钟轮询一次，
两次采样之间计数器已经转过好几圈了——**你算出来的速率完全是错的。**

**错成什么样？**假设真实流量是 500 Mbps，5 分钟轮询一次：

  真实增量 18.8 GB，取模之后读到 1.6 GB。
  算出来是 42 Mbps，真实是 500 Mbps，**差了 12 倍**。

**三个解法**，按优先级：

1. **用 64 位计数器**：`ifHCInOctets`／`ifHCOutOctets`（HC 就是 high capacity）。
千兆要跑 4687 年才回绕。**这是正解。**
2. **缩短轮询间隔**：至少短于回绕周期。
千兆要 30 秒以内，万兆要 3 秒以内——**这在设备多的时候根本做不到。**
3. **判断回绕**：如果这次读数比上次小，就按回绕补偿。
**但这只能处理「一圈」，转两圈就完全没法补。**

**顺带记住 SNMP 的三个版本差异**：v1 明文、v2c 明文加 community、**v3 有认证与加密**。
生产网应该用 v3——v2c 的 community 在网络上是明文传的。

千兆 34.4 秒——这个数要背下来。万兆 3.4 秒，意味着万兆口上「每分钟采一次」根本没法用。

表里最后 100 Gbps 是 0.3 秒——这已经短到「比人的反应还快」， 所以高速口不用 64 位计数器就完全没法监控。

那个具体例子最能说明问题：真实 500 Mbps、5 分钟轮询一次，真实增量 18.75 GB， 取模之后读到 3.0 GB，算出来只有 80 Mbps——差 6 倍多。 而这张图看起来「很平滑」，没有任何报警。

30 秒实验

  1. 查网管软件用的是 32 位还是 64 位计数器。
  2. 看轮询间隔是多少秒。
  3. 算一下你的端口速率下计数器多久回绕。

常见误区

  1. 用 32 位计数器监控千兆以上端口。会回绕。
  2. 以为轮询越勤越准。勤了会增加设备负担。
  3. 用 SNMPv2c 传 community。明文，等于没有认证。
自测三问（点开对答案） 1. 32 位计数器在千兆口上多久回绕？ —— 约 34.4 秒。 2. 正解是哪个 OID？ —— ifHCInOctets／ifHCOutOctets，64 位版本。 3. SNMPv3 比 v2c 强在哪？ —— 有认证与加密，community 不再是明文。

下一节：功能讲完了，最后四节看「设备里面」——架构。

相关笔记