sar -n DEV 显示 rx_error / tx_error 增长但业务无丢包的网卡驱动问题

rx_errors/tx_errors 增长但无实际丢包，大概率是驱动误报而非物理故障；应通过 ethtool - S 查看 rx_crc_errors、rx_missed_errors 等细分计数，并结合驱动版本、固件及 offload 配置综合判断。

rx_error / tx_error 增长但 ping 和业务流量无丢包，先别急着换网卡

这大概率不是物理链路或交换机问题，而是驱动把非致命错误（比如 CRC 校验失败但帧仍被接收、DMA 描述符状态误报）计入了 rx_errors 或 tx_errors。Linux 内核的 ethtool -S 会暴露更细粒度的寄存器计数，而 sar -n DEV 只聚合了驱动上报的 rx_errors 字段——它本身不区分“真丢包”和“驱动误报”。

用 ethtool -S 对比真实丢包与驱动误报

运行 ethtool -S eth0（替换为实际网卡名），重点看这几类字段：

• rx_crc_errors、rx_frame_errors：若持续增长，且 rx_packets 同步增长，说明帧被接收但校验失败——上层协议 栈可能已静默丢弃（如 IP 层 checksum fail），但驱动仍计入 rx_errors
• rx_missed_errors：环形缓冲区溢出导致丢包，对应内核 netdev_rx_dropped，这类才是真丢包
• tx_aborted_errors、tx_carrier_errors：物理层异常（如链路闪断、协商失败），但若 tx_packets 正常递增，说明重传成功，驱动只是记录了中间态错误
• rx_long_length_errors、rx_short_length_errors：常见于 MTU 不匹配或网卡 offload 配置冲突（如 GSO 开启但对端不支持）

检查驱动版本与已知 bug

同一款网卡（如 Intel ixgbe、Broadcom bnxt_en）在不同内核版本中，rx_errors 的统计逻辑可能变化。常见触发场景包括：

• 启用了 rx offload（如 gro、lro）但硬件 FIFO 溢出，驱动将部分帧标记为 error 而非 drop
• DPDK 或 SR-IOV 场景下，PF 驱动未正确同步 VF 的错误计数
• 特定固件版本（如 Mellanox CX-5 的 FW 16.28.x）存在 rx_errors 误增 bug，需升级固件
• 使用 ethtool -i eth0 查看 driver 名和 version，然后搜索“[driver name] rx_errors false positive”

临时缓解与长期规避建议

如果确认是驱动误报且业务稳定，可暂缓升级；但需注意监控维度是否被污染：

• 避免用 sar -n DEV 的 rxerr/s 作为告警指标，改用 netstat -s | grep -A 5 "TcpExt:" 中的 TcpExtTCPAbortOnMemory 或 ip -s link show eth0 的 dropped 字段
• 关闭可能引发误报的 offload：ethtool -K eth0 gro off lro off（测试后观察 rx_errors 是否停止增长）
• 若必须保留 offload，升级到内核 5.10+ 或对应驱动的最新 stable 版本（如 ixgbe 5.14.7+ 已修复多处 rx_errors 误计）
• 某些驱动（如 vmxnet3）的 rx_errors 完全不可信，只能依赖 guest 内 /proc/net/dev 的 rx_dropped 和应用层重传率交叉验证

真正麻烦的是那些错误计数和业务抖动时间点强相关的 case——这时候 rx_errors 往往是表象，背后可能是内存 DMA 映射失败或 IRQ 绑核不均，得抓 dmesg -T | grep -i "eth|dma|irq" 看实时内核日志。