错误计数器概述：常见的MAC错误计数器种类
做网络设备调试这些年，我见过太多人一看到丢包就慌神。其实丢包本身不可怕，可怕的是你看不懂错误计数器在说什么。MAC控制器内部那些计数寄存器，就像飞机的黑匣子——记录了每个帧在链路层经历的所有异常。我个人习惯，拿到一台设备，第一件事就是清空所有计数器，然后制造一个已知流量，再回读日志。这样，哪个计数器关联什么类型的错误，心里就门儿清了。
CRC错误（帧校验序列错误）
这是MAC层最常见的丢包原因，说白了就是帧在传输过程中被噪声或信号反射搞坏了。发送方会在帧尾附加4字节的CRC32校验值，接收方收到后重新计算一遍。如果计算结果和收到的CRC对不上，这个帧就会被丢掉。
我建议你记住一个细节：CRC错误不只由物理层问题引起。我记得有一次项目调试，用户抱怨某个端口疯狂跳CRC错误，示波器看了波形也没问题。最后发现是那个端口的MAC芯片寄存器校验模式配错了——它配成了裁剪后校验，而交换芯片发过来的却是带FCS的完整帧。所以，排查时除了查线缆，还得确认MAC的CRC计算模式（IEEE 802.3 vs Ethernet II）。
帧长度错误
以太网标准规定有效帧长度必须在64字节到1518字节之间（不包括前导码）。超过这个范围的帧，MAC控制器会直接丢弃，并累加对应的计数器。
- 超短帧（Runt）：长度小于64字节。通常是冲突导致的碎片（Collision Fragment），或者PHY层误判了信号结束位置。我个人排查Runt，首先看是不是半双工模式下冲突太多，其次检查PHY的载波侦听阈值。
- 超长帧（Giant）：长度大于1518字节（如果支持Jumbo帧则上限更大）。常见原因是上层软件往MAC环里塞了超出最大负荷的数据包，或者硬件FIFO溢出导致尾部填充出错。嗯，这里要注意：Jumbo帧需要端到端都支持，否则中间设备会当Giant丢掉。
对齐错误（Alignment Error）
这个词在网络工程师圈子里有点冷门，但实际排查中很实用。对齐错误是指帧的最后一个字节没有完整结束在整字节边界上——说白了就是收到了一个“半截字节”。
我在项目中遇到过一台老交换机，配了劣质SFP模块，光信号抖动太大，导致恢复出的数据时钟漂移，时不时冒出来几个对齐错误。解决办法就是换模块，换完计数器归零。
注意：很多MAC芯片会把同时出现CRC错误和对齐错误的帧只记录为对齐错误（因为两者往往伴随出现），你读计数器时要看芯片手册的具体定义。
冲突计数（Collision Count）
这个东西在半双工时代是主角，现在全双工链路基本看不到了。但如果你排查的还是10/100M半双工网络（比如老旧工控设备），冲突计数器就是你的好帮手。
- 单次冲突（Single Collision）：帧成功发送前只产生了一次冲突。
- 多次冲突（Multiple Collision）：经历了2~15次冲突才发送成功。
- 过量冲突（Excessive Collision）：冲突超过16次，帧被丢弃。
- 延迟冲突（Late Collision）：冲突发生在64字节以后（正常冲突只发生在帧前64字节内）。我曾经在布线不规范的项目里见过延迟冲突——线缆距离超长，发送方已经发送完64字节才开始检测到冲突。这种错一般直接指向物理拓扑问题。
其他常见计数器
除了上面几个，MAC错误计数器的大家族里还有这些成员，我按经验罗列一下。
| 计数器名称 | 含义 | 排查提示 |
|---|---|---|
| FCS错误 | 和CRC错误是同一个东西，不同厂商命名不同 | 如果同时查到了FCS错误和CRC错误，通常是两个不同的寄存器，加总才是总错误数 |
| Runt错误 | 帧长度小于64字节 | 先看CRC是否也错误，如果Runt+CRC同时出现，大概率是冲突碎片 |
| Giant错误 | 帧长度超过1518/1522字节 | 检查网络内是否有不支持Jumbo的设备，或者软件MTU配置溢出 |
| 长度/类型字段错误 | 长度字段的值与实际帧长度不匹配（老式802.3帧） | 一般出现在配置错误的网桥或双栈模式下 |
| 传输异常中止 | 发送过程中MAC主动放弃了发送（如内部FIFO下溢） | 多见于CPU负载高或总线带宽不足的场景 |
小结
MAC错误计数器是网络设备健康状态的晴雨表。你不需要背下每一种计数器的比特位定义，但需要形成一种直觉：看到CRC错误立即怀疑物理层或线缆；看到冲突计数立刻检查双工模式；看到Runt和Giant先确认链路两端MTU是否一致。我个人的工作惯例是，在每次升级或更换硬件后，先保存一份所有MAC错误计数器的快照，运行一周后对比，哪个计数器涨得最多，那个方向就是排查的重点。