真正代表网卡层丢包的是rx_discards、rx_errors和rx_fifo_errors；三者任一非零且5分钟内增长＞10，结合ocssd.log中CRS-1611密集出现，即可定位为网卡硬件或驱动层故障。
直接看 ethtool -S 输出里的 rx_discards、rx_errors 和 rx_fifo_errors，只要非零，基本可断定是网卡层丢包，不是 Oracle 配置或 SQL 问题。
查网卡底层丢包计数必须用 ethtool -S，别信 ifconfig 的 dropped
ifconfig 显示的 dropped 是内核协议栈层丢包（比如 socket buffer 满），和私网心跳中断无关；而 RAC 节点驱逐真正触发点是网卡硬件收不到包。所以必须盯死 ethtool -S eth1 里这三项：
-
rx_discards：网卡驱动主动丢弃，常见于 Ring Buffer 溢出或中断风暴 -
rx_errors：物理层错误，如 CRC 校验失败、对端交换机 QoS 限速、光纤衰减 -
rx_fifo_errors：接收 FIFO 缓冲区溢出，说明 CPU 来不及处理中断或绑定不均
若其中任一值在 5 分钟内增长 >10，且与 ocssd.log 中 CRS-1611 时间戳重合，就是根因。
ocssd.log 里 CRS-1611 出现频率比数值更重要
单次 CRS-1611 in 6.512 seconds 不代表严重问题；但若每 30 秒密集出现 3–5 次，且多节点同步发生，说明心跳包批量丢失——这时再回头查 ethtool -S 就不是“验证猜想”，而是“定位故障源”。注意两个细节：
- 日志里
in X.XXX seconds的 X 越小（如in 0.823 seconds），说明网络恢复窗口越窄，丢包越集中 - 若只有 node1 报
CRS-1612 this node was evicted by node2，而 node2 完全没CRS-1610，大概率是 node1 自身网卡收包异常，不用查 node2 网络
别跳过 netstat -s 里的 reassembles failed
RAC GC 消息常达数 KB，MTU=1500 必然分片；任意一个分片丢包，整个消息就失效，表现为 gc cr block lost。此时 netstat -s | grep "reassembles failed" 会持续上涨，这是 MTU 不足 + 丢包的铁证。修复后该值必须归零或停止增长，否则改了 ethtool 参数也白搭。
真正难的不是发现丢包，而是确认丢包发生在哪一层：是网卡 FIFO 溢出？交换机 ACL 误拦 UDP？还是 HAIP 初始化时被 rp_filter=1 静默丢弃？每种路径对应不同日志和命令组合，漏掉一层，诊断就绕远路。
