3、CRC 错误计数器详解：原理、产生原因、对丢包的影响
3.1 先聊聊 CRC 的原理，这个绕不开
做网络排查这么多年，我每次看到别人的数据流不通，第一反应就是去查端口统计。而 CRC 错误计数器，几乎每次都能揪出一些妖蛾子。为什么要先讲它？因为以太网帧从物理层扒下来之后，MAC 层最先干的事就是做循环冗余校验（CRC）。
说白了，发送端把整个帧（目的 MAC、源 MAC、Type/Length、Payload）当成一个二进制大整数，除以一个预设的生成多项式。常见的是 CRC-32，多项式是 0x04C11DB7。除完之后得到一个 32 位的余数，这就是 FCS（帧校验序列），塞在帧尾。接收端拿到这个帧，重新用同一个多项式除一遍。如果除出来的余数恰好是 0，就说明帧没问题；否则 … 嗯，你猜到了。
关键点：只要有一位翻错了，CRC 几乎必出报警。 算出来的余数不是简单的奇偶校验，它的汉明距离能扛住大量随机错误。所以我见过很多同事以为“只错几个比特没事”，其实 CRC 连打孔法都不放过的。
| 特性 | 值 |
|---|---|
| 生成多项式 | 0x04C11DB7（二进制 33 位） |
| 校验位长度 | 32 bit（4 Byte） |
| 错误检测能力 | 所有 1~2 bit 错误、奇数 bit 错误、≤32 bit 突发错误（概率极高） |
| MAC 层丢弃依据 | CRC 失败 → 帧直接被扔掉，绝不交上层 |
3.2 CRC 错误计数器的真相
每个以太网端口，在 MAC 接收侧都有一个硬件寄存器，专门记录“CRC 校验失败”的次数。这个计数器只增不减，除非你手动清。我习惯在排查时先看 show interface 里的 CRC errors 或者 FCS errors，它们通常指同一个东西。
注意，有些平台把短帧（runt）和有 FCS 错误的帧分开统计，但大多数直接合并成 CRC 错误。实际工作中，你看到 CRC 飙升，首先要确认是不是物理层在搞鬼。
3.3 产生原因——我遇到过的一些“真凶”
说到底，CRC 错误只代表一件事：比特流在传输过程中发生了变异。但为什么变异？这里我列几个高频元凶。
- 物理层噪声/干扰：双绞线附近的电机、变频器、大功率无线电。有一次客户工厂车间里，机器一启动，交换机端口 CRC 就开始疯长。
- 链路质量差：水晶头氧化、线序不对、传输距离超 100 米。我记得帮一个机房排查，换了根跳线，CRC 直接从 0 跳到几十万，一查原来是线序乱七八糟。
- 双工不匹配：一边全双工，一边半双工，碰撞引起的帧碎片被误判为 CRC 错误。这种情况在老旧交换机上经常出现。
- 时钟漂移/抖动：特别是长距离光纤传输，时钟恢复没做好，采样点偏移，导致比特错位。
- 网卡硬件故障：NIC 的缓存或 DMA 通道出问题，送出的帧就已经坏了。
- 交换机/路由器内部错误：背板接口的信号完整性下降，或转发芯片缓冲溢出后重写 FCS 出错。
小经验： 如果 CRC 错误只在某个端口偶尔出现，而且伴随大量输错过错误（如 runts、giants），往往就是双工或电缆引起的。但如果是“稳定”的每秒几十个错误，且全交换机都有，那就要怀疑上联设备或光模块了。
3.4 对丢包的影响
CRC 错误的帧会被 MAC 层直接丢弃，这就是最彻底的丢包。上层协议（TCP）只能靠超时重传找回数据，但重传过程会引入延迟和带宽浪费。
我来算一笔帐：如果链路上有 0.1% 的 CRC 错误率，那么一个 1 KB 的 TCP 段就有约 1/1000 的概率被丢。TCP 的拥塞控制窗口一旦检测到丢失，就会瞬间减半，吞吐量直接腰斩。我在项目中见过一条千兆链路因为 0.5% 的 CRC 错误，实际吞吐只有 200 Mbps，排查了三天才发现是光纤接头没插紧。
# 快速评估影响（基于 tcpdump 统计）
# 假设正常帧数 1,000,000，CRC 错误帧 1,200
# 误帧率 ≈ 0.12%
# TCP 重传率通常会放大 2~5 倍，实际有效吞吐 ≈ 正常带宽 × (1 - 误帧率)^4
3.5 避坑指南
我曾经踩过一个坑：交换机上一端口 CRC 一直跳，但该端口连接的服务器业务正常。查了半天才发现服务器网卡开启了 “巨型帧”，而交换机没配接收巨型帧能力。超过 1518 字节的大帧在交换机侧会被截断，FCS 自然对不上，计数器就疯狂涨。最终服务器重传成功，但交换机统计却吓死人。
所以，看到 CRC 错误飙升，先别急着换线。按下面几步走：
- 确认对端是否支持同样的 MTU（看看有没有巨型帧误配）。
- 检查自协商结果，强制模式和自协商导致的双工不匹配。
- 排查物理层：换线、换端口、换光模块。
- 对比两端计数器的值，判断错误来自链路还是设备内部。
重要： 许多交换机在统计 CRC 错误时，不会把“过短帧”或“对齐错误”算进去，但有些会把它们合并。你一定要确认平台文档里的计数器定义，否则会被骗。
3.6 知识体系：从发送到丢弃的流程
下面这张图帮你把整个过程串起来。注意看每一步可能出现歪曲的地方。
看到没有？唯一能挽救这个帧的，只有上层协议的重传机制。而重传又带来 RTT 翻倍、窗口减半、吞吐暴跌。所以 CRC 错误率越高，掉速越明显。