rx_crc_errors持续非零是物理层信号完整性问题的直接证据，表明网卡收到但校验失败的包增多，常见于光纤衰减、网线超长、光模块不匹配或端口硬件故障。
查 ethtool -S 输出里的 rx_crc_errors
私网出现 crc 错误，最直接证据就是 ethtool -s bond1 | grep rx_crc_errors（或对应物理口如 ens2f0）返回值持续非零。这个字段代表网卡在物理层校验失败的接收包数量，不是丢包，而是“收到但确认是坏的”。一旦上涨，说明链路存在信号完整性问题。
常见原因包括：
- 光纤衰减超标（尤其多模短距场景下接头污染、弯折或跳线老化）
- 网线质量差或长度超限（超 100 米时千兆铜缆极易出 CRC）
- 光模块型号不匹配（例如单模模块插在多模光纤上）
- 交换机端口或网卡端口 PHY 层硬件故障
ifconfig 的 errors 字段是否同步增长
ifconfig bond1 输出中的 errors 字段，本质是内核对底层错误（含 CRC）的汇总上报。如果 rx_crc_errors 上涨而 ifconfig 的 errors 没变，大概率是驱动未将该类错误透传给网络栈——这本身已是异常信号，需升级网卡固件或驱动。
但更常见的是两者同步增长，此时可确认：问题真实存在于物理链路，而非配置或软件参数。不要尝试调大 net.core.rmem_max 或禁用 GRO/LRO，这些对 CRC 错误完全无效。
交换机侧是否报 %ETHCNTR-3-LOOPBACKDETECTED 或链路震荡日志
CRC 错误常伴随物理层不稳定，交换机会记录相应事件。登录私网交换机后执行：
- 华为/华三：
display logbuffer | include "CRC\|error\|down" - Cisco：
show logging | include "CRC\|err\|link down"
若发现 %ETHCNTR-3-LOOPBACKDETECTED 或反复的 interface X/X/X, changed state to down，基本锁定为线缆接触不良、光模块供电异常或端口硬件损坏。此时替换跳线、清洁光纤接头、更换光模块是最高效动作，别花时间查 Oracle 参数。
为什么 ping 看不出 CRC 问题
ping -c 100 node2-priv 即使显示 0% loss、延迟稳定，也不能排除 CRC 错误。因为 ICMP 包被丢弃时不会触发 CRC 校验失败（它走的是不同路径和缓冲区），而 RAC 私网流量（UDP + HAIP + LMS 发包）才真实暴露物理层缺陷。
真正有效的验证方式是：
- 在节点 A 执行
tcpdump -i bond1 -c 1000 'udp port 65000' -w /tmp/priv.pcap（RAC 默认 UDP 端口范围） - 在节点 B 同步抓包，用 Wireshark 对比：是否存在大量 “Bad checksum” 或 “Malformed packet” 标记
- 若存在，且与
rx_crc_errors增速匹配，即可闭环定位
CRC 错误从不“安静”，它总在 ethtool 和交换机日志里留下硬性痕迹；忽略它去调数据库参数，只会让驱逐越来越频繁。
