Oracle RAC节点驱逐的真正条件是任一关键心跳路径（网络、磁盘或本地）在超时窗口内持续不可达，由cssd综合判断并需多数派节点共识，而非仅因网络心跳丢包即触发。
防火墙拦截根本不会导致“心跳超时”——它只会让心跳彻底断掉，连超时都算不上。 oracle rac 的心跳（cssd 层）走的是私网 udp 端口（默认不限定具体端口号，由 cssd 动态绑定），不走 1521。开放 1521 对心跳毫无意义，反而可能暴露监听器给外部攻击。
为什么查不到心跳包，却看到大量 CRS-4530 或 WARNING 192.168.11.0 could not be translated
这类日志不是“超时”，而是 CSSD 根本发不出包：要么私网接口没配进 OCR，要么系统层二层不通，要么防火墙直接丢弃了 UDP 包且不回 ICMP unreachable。
- 用
tcpdump -i eth2 udp portrange 1024-65535 -c 10在私网接口抓包，若完全无收发，说明流量被静默丢弃 -
arping -I eth2 10.0.0.102失败比ping更能定位二层阻断（ICMP 可能被禁，ARP 不依赖 IP 层策略） - 检查防火墙是否启用了
rp_filter（反向路径过滤）：sysctl net.ipv4.conf.eth2.rp_filter，值为1且路由不对称时会丢私网回包
RAC 私网通信实际需要放行哪些端口和协议
Oracle 官方明确不固定端口，但必须保障以下底层能力：
- UDP 全端口双向通行（
cssd、ohasd、oraagent均动态绑定） - ICMP Type 3（Destination Unreachable）、Type 8（Echo Request）用于基础连通性诊断
- TCP 2016（GIPCD 心跳探测端口，19c 默认启用，不可改）
- 避免使用 “仅放行 1521+2016” 这类错误策略——私网通信不经过监听器，
1521是业务端口，与集群健康无关
云环境或强管控网络下最易踩的坑
在 Azure/AWS/阿里云跨 AZ 部署时，安全组/NACL 往往只允许“已建立连接”的返回流量。而 CSSD 心跳是周期性单向 UDP 包，没有 TCP 的三次握手状态，会被默认拒绝。
- 必须显式添加入方向规则：源 = 对端私网 CIDR，协议 = UDP，端口 =
0-65535 - 出方向规则也要放开：目标 = 对端私网 CIDR，协议 = UDP，端口 =
0-65535 - 不要依赖“RELATED,ESTABLISHED”——UDP 没有连接状态，这条规则对心跳无效
- HAIP（
169.254.x.x）地址通信失败也会表现为 ASM 启动卡住，但它同样走 UDP 动态端口，不是1521
真正要盯死的，从来不是端口号，而是私网接口是否被正确注册进 OCR、arping 是否通、以及防火墙是否把 UDP 当“无状态垃圾包”全盘丢弃。端口白名单思维在 RAC 私网场景下本身就是个陷阱。
