查不到cssd心跳包说明流量被防火墙静默丢弃，需用tcpdump -i eth2 udp portrange 1024-65535 -c 10验证；oracle rac私网udp通信端口动态绑定，云环境须显式放行双向0-65535端口，禁用“related,established”规则，并检查arping、rp_filter及mtu一致性。
查不到cssd心跳包？先确认是不是被防火墙静默丢弃
抓包命令tcpdump -i eth2 udp portrange 1024-65535 -c 10在私网接口执行，若完全无收发记录，说明流量在系统层就被拦截了，不是网络延迟问题。Oracle RAC私网通信（cssd、gipcd、HAIP）使用动态绑定的UDP端口，官方明确不固定端口号。云环境（AWS/Azure/阿里云）安全组/NACL默认只允许“已建立连接”的返回流量，但UDP无连接状态，“RELATED,ESTABLISHED”规则对心跳无效。
必须配置两条规则：
- 入方向：源 = 对端私网 CIDR，协议 = UDP，端口 =
0-65535 - 出方向：目标 = 对端私网 CIDR，协议 = UDP，端口 =
0-65535
别省事，漏一条就可能卡在ora.cluster_interconnect.haip资源启动阶段。直接开1521端口没用，反而暴露监听器。
arping比ping更可靠：失败即表明二层不通
arping -i eth2 10.0.0.102不依赖IP层策略，失败即表明二层不通——常见于云安全组默认拒绝ARP，或交换机ACL限制。如果arping不通但ping通（或反过来），说明问题不在路由层，而在链路层或ARP表同步异常。
检查反向路径过滤是否启用：sysctl net.ipv4.conf.eth2.rp_filter，值为1且路由不对称时，私网回包会被内核丢弃。临时关闭可验证：sysctl -w net.ipv4.conf.eth2.rp_filter=0，但生产环境需修正路由而非长期禁用。
netstat -s里packet reassembles failed增长？UDP分片重组失败
执行netstat -s | grep "fragments dropped after timeout"或netstat -s | grep "reassembles failed"，非零即表示UDP分片在内核层面未能及时重组。常见原因包括：
- 网卡中断绑定单CPU导致软中断堆积（尤其百核服务器）
- MTU不匹配：交换机MTU=1500 vs 服务器MTU=9000，形成MTU黑洞
- UDP接收缓冲区过小：
sysctl net.core.rmem_max低于20MB风险高
调优建议：统一私网设备MTU为9000（Jumbo Frame），增大rmem_max至25165824，并用ethtool -L eth2 combined 4分散中断队列。
gc cr block lost持续出现？先看GV$SYSTEM_EVENT等待桶分布
别急着换网线。查GV$SYSTEM_EVENT中gc cr block busy和gc current block busy的TIME_WAITED_MICRO按毫秒桶分布：
- 大量等待集中在
16ms桶（即16–32ms区间）→ 真实网络抖动或瞬时中断 - 集中在
1ms或4ms桶 → 90%以上是锁争用、未绑定变量SQL、全表扫描JOIN导致GC流量激增
配合GV$SQL查buffer_gets/executions高但disk_reads/executions低的语句——这类SQL在单实例飞快，在RAC上却疯狂触发GC，是典型的“假丢包”源头。
netstat -s开始，而不是一上来就调Oracle参数。
