必须用oifcfg getif确认标记cluster_interconnect的接口，再通过tcpdump抓6200端口包验证真实流量路径，而非依赖配置文件或ping测试。
确认当前生效的interconnect接口是否真实承载心跳流量
oracle rac的私网通信不认配置文件里“写进去”的网卡，只认oifcfg getif输出中标记为cluster_interconnect的那个接口。很多dba改完oifcfg setif就以为万事大吉，结果没重启crs，或者把public网卡误标为interconnect，导致所有gcs/ges流量实际走错路径。
实操建议：
- 先运行
oifcfg getif，确认输出中带cluster_interconnect标记的接口名（如enp0s9/10.10.10.0:cluster_interconnect） - 用
ip addr show enp0s9核对该接口是否UP、IP地址是否在预期子网内、状态是否LOWER_UP - 在两个节点上同时执行
tcpdump -i enp0s9 -c 100 'host 10.10.10.2 and port 6200'，看是否有持续进出的TCP SYN/ACK包——这才是GCS真实使用的通信路径 - 别用
ping测延迟：ICMP可能被QoS限速或走不同路由；改用hping3 -c 10 -p 6200 -S 10.10.10.2模拟GCS建连行为
用iperf3模拟RAC真实UDP小包负载测吞吐
iperf3单流TCP测试结果再高也没用，因为RAC的Global Cache Service大量使用128–512字节的UDP短包（block pin/unpin、SCN同步），受MTU、RSS队列分布、中断合并影响极大。单流iperf3只能反映链路理论带宽，掩盖真实瓶颈。
实操建议：
- 用
iperf3 -u -b 0 -l 128 -P 32：UDP协议、不限速、128字节包、32并发流，贴近GCS典型包大小和并发模型 - 检查接收端中断分布：
cat /proc/interrupts | grep enp0s9，若所有中断集中在单个CPU核，说明RSS未生效，需执行ethtool -X enp0s9 equal 4（按实际CPU数调整） - 禁用TSO/GSO：
ethtool -K enp0s9 tso off gso off，否则网卡会把小包强行聚合，掩盖底层小包处理能力不足 - 交换机侧确认Jumbo Frame已全局启用：两端网卡MTU=9000，交换机端口MTU也必须设为9000，否则包会被静默丢弃
排查HAIP多播注册失败导致的隐性延迟
ora.cluster_interconnect.haip资源显示OFFLINE，但ping私网IP又通，这是典型HAIP多播通信失败。HAIP依赖UDP多播（默认端口42424）完成节点发现和地址漂移，而这个多播链路极易被交换机IGMP Snooping或系统rp_filter掐断。
实操建议：
- 抓包验证多播通路：
tcpdump -i enp0s9 'multicast and port 42424'，一端发包另一端收不到，基本锁定交换机侧问题 - 临时关闭交换机IGMP Snooping——若HAIP立刻恢复ONLINE，说明是IGMP querier缺失导致多播组注册超时
- 检查系统rp_filter：
sysctl net.ipv4.conf.enp0s9.rp_filter必须为0或2，不能是1（严格反向路径检查会丢弃多播响应包） - 绕过HAIP直测：在
/etc/hosts里静态绑定对方HAIP到物理IP，再跑oifcfg getif看是否识别为interconnect，可排除DNS/GNS干扰
从OS层确认私网二层连通性与MTU一致性
很多“心跳延迟”根本不是Oracle层面的问题，而是OS层arping不通、MTU不一致或rp_filter拦截。尤其当私网两端MTU一个设9000、一个留1500时，HAIP握手包会被静默丢弃，日志里只报“no network HB”，毫无具体线索。
实操建议：
- 用
arping -I enp0s9 -c 3 10.10.10.2验证二层可达性，比ping更可靠（绕过ICMP策略） - 两端统一执行
ip link set dev enp0s9 mtu 9000，并确认交换机端口MTU同步调整 - 用
ping -M do -s 8972 10.10.10.2测试巨帧：成功返回说明MTU=9000通；若提示Frag needed and DF set (mtu = 9000)，说明包大小刚好踩线；若报Message too long，说明实际MTU仍为1500 - 查
netstat -s | grep -A 2 "IpReasmFails\|reassembly"，该值持续增长说明存在IP分片重组失败，是MTU不一致的铁证
