4. 帧长度错误计数器：超长帧、超短帧、符号错误
聊完了 CRC 校验，咱们继续往下走。这一章要聊的东西，跟“尺寸”有关。
你可以想象一下，以太网帧就像快递包裹。网络设备（就是咱们的交换机、路由器）在收件的时候，会先检查包裹大小是否符合标准。太大？超重了。太小？可能是个空盒子，或者碎掉了。这里面涉及到三类最常见的长度错误：超短帧、超长帧，还有符号错误。这些错误在 MAC 层的计数器里都有对应的“罪名”，排查的时候一翻就能看到。
4.1 超短帧（Runt Frame）
什么叫超短帧？简单说，就是小于 64 字节的帧（不包括前导码和定界符）。以太网标准里规定，帧的最小长度是 64 字节。这 64 字节里，包含了 MAC 地址、类型/长度字段、数据字段和 FCS（帧校验序列）。
为什么要有这个下限？我举个例子你就明白了。以太网在发送数据时，是边走边发。如果帧太短，在信道还没有检测到冲突之前，这个帧就可能已经发完了。这会导致什么问题？早期共享式以太网靠 CSMA/CD 协议工作，帧太短的话，冲突检测机制就失效了。虽然在交换式网络里这个问题弱化了，但 64 字节的规范一直沿用至今。
常见成因：
- 驱动 Bug： 我在一次数据中心项目中遇到过，某款网卡在特定驱动版本下，偶尔会发出 62 字节甚至 60 字节的包。原因后来查明是驱动程序在拷贝 DMA 缓冲区时，没有正确填充到最小值。
- 物理层截断： 信号在传输过程中，如果遇到强烈的电磁干扰，可能会导致帧在传输中途被“砍断”。我曾经碰到过一根网线芯线断了，但外皮完好的情况，交换机上就疯狂报超短帧错误。
- PHY 芯片故障： 有时候信号被错误地提前终结了，MAC 层收到的长度就不够 64 字节。
Symbol Error 或 CRC Error。如果只有一端报超短帧，另一端正常，那问题大概率出在中间传输介质上。
4.2 超长帧（Jumbo Frame / Oversized Frame）
有短的，自然就有长的。超长帧是指大于标准 MTU（最大传输单元）的帧。传统的以太网 MTU 是 1500 字节。现在很多数据中心会启用 Jumbo Frame，把 MTU 设置为 9000 字节或更大。
你要注意：超长帧 和 Jumbo Frame 不完全是一个概念。Jumbo Frame 是故意配置的大帧，整个网络都支持。超长帧则是“不速之客”，它超过了端口配置的最大帧长度。所以你会看到 MAC 层的计数器里通常有两个相关项：Oversized Frames 和 Jumbo Frames（或类似的命名）。
为什么超长帧会引发丢包？
- 超出接口处理能力： 交换机的 ASIC（专用集成电路）在收到一帧时，会检查帧长度。如果长度大于端口配置的接受上限，直接丢弃。
- 缓冲区不足： 即使端口允许 Jumbo Frame，但如果设备的片内缓冲区不够大，大帧可能导致缓存溢出。我的经历里，有一次就是服务器发送的 Jumbo Frame（9014字节），正好交换机之间链路带宽不够，大帧在缓存里排队时间过长，导致对端超时重传，网络性能暴跌。
| 帧类型 | 长度范围（不含前导码） | 常见场景 |
|---|---|---|
| 标准以太网帧 | 64 ~ 1518 字节 | 默认配置，兼容性好 |
| 超长帧（Oversize） | 大于端口允许的最大长度 | MTU 不匹配、配置错误 |
| 巨型帧（Jumbo） | 通常 1519 ~ 9000 字节 | 存储网络、大数据传输 |
4.3 符号错误（Symbol Error）及其与帧长度的关联
这里有个容易混淆的地方：符号错误听起来像是物理层的事情，但它为什么会被归到帧长度错误计数器里？
你想想看，以太网是串行通信，8 位数据通常被映射成一组符号（比如 4B/5B 或 8B/10B 编码）。物理层收到连续的符号流，会尝试解码成比特流，然后组帧。如果解码失败，比如遇到了非法的符号序列，那物理层可能会产生一个符号错误中断。这时候接收到的比特流可能不完整，或者长度完全是乱的。MAC 层发现解析出来的帧长度不合法，就随手把它算作帧长度错误。
说白了，符号错误是底层的“原材料”污染了，导致上层（MAC 层）无法正确还原帧结构。这跟帧长计算有直接关系。
典型的符号错误触发场景：
- 信号质量太差： 电缆过长、连接器氧化、收发器光电转换异常。
- 时钟漂移： 两端设备的主时钟源不一致，或者锁相环锁不住，导致采样位置不对。
- 电磁干扰： 尤其是在工业环境里，变频器、大功率电机开启瞬间，会在网线上感应出尖峰脉冲。这个脉冲一旦落在符号的判决边界，就可能导致错误。
Symbol Error 和 Short Frame / Long Frame 计数器递增，我通常会先去拔插那条网线，或者换一根已知的测试线。有一次，80% 的符号错误都是因为水晶头弹片断了一截，接触不良造成的。更换后计数器就不再增长了。
4.4 关键计数器解读与排查策略
在实际的设备上，你可能看到的计数器名称五花八门。比如 Cisco 交换机上叫 Runts、Giants、Frame-Too-Long；华为设备上可能是 Undersized packets、Oversized packets。但核心思路是一样的。
我建议用下边这个逻辑去排查：
- 第一步： 抓出哪个接口的哪个计数器在持续增长。
show interface counter errors这类命令很有用。 - 第二步： 如果超短帧和超长帧只在一个方向上（Input 或 Output）增长，更可能是本地问题；如果两端都有，可能是链路问题。
- 第三步： 查看物理层统计。比如
CRC、Symbol Error、Alignment Error。如果这些也在涨，那就是物理层故障。反之，如果只有长度错误，而 CRC 没错误，那很大概率是上层配置或驱动的问题。 - 第四步： 检查 MTU。拿两个终端互 ping 带 DF 标志的大包，确认整个链路的 MTU 端到端一致。我记得有一次，一个运维同事就是忘记了某台汇聚交换机上配置了
ip mtu 1400，导致所有超 1400 字节的帧都被认为是超长帧。
嗯，做网络排查，很多时候就是玩这种“排除法”。计数器不骗人，关键是你得知道它在说什么。这一章的内容，说白了就是帮你理解“尺寸”这个维度的异常信号。下次在交换机上看到 0 Giants，别光高兴，先确认一下你们的 MTU 设置是不是统一的。