oracle rac互信检查失败的根本原因在于runcluvfy.sh要求ssh连接严格无密码、无交互、无警告、无banner输出，而手动ssh成功不代表满足该静默要求；必须确保uid/gid一致、禁用sshd_config中干扰项、清理.ssh/config、使用batchmode=yes测试，并统一私网mtu与selinux策略。
节点互信失败时 ssh 连通性看似正常但 runcluvfy.sh 报错
Oracle RAC 安装前的互信检查不是只看 ssh user@node2 能否登录，而是要求无密码、无交互、无警告、无 banner 输出——任何干扰都会导致 runcluvfy.sh stage -pre crsinst 在 “User equivalence” 阶段失败。常见现象是手动 ssh 成功，但脚本报 PRVF-4037 : User equivalence check failed。
实操建议：
- 必须用安装用户（
grid或oracle）执行，且两节点 UID/GID 完全一致：id grid对比输出，不一致会直接失败 - 禁用
/etc/ssh/sshd_config中的PrintLastLog、PrintMotd、StrictModes yes（临时设为no测试用） - 检查
~/.ssh/config是否存在 Host 别名或 ProxyCommand，这些会破坏静默连接；临时重命名为config.bak再试 - 验证命令必须加
-o ConnectTimeout=10 -o BatchMode=yes：例如ssh -o BatchMode=yes -o ConnectTimeout=10 grid@node2 date，失败即说明互信未达标
runcluvfy.sh 提示 “Node connectivity” 失败但 ping 和 nc 都通
这个阶段检查的是私网接口（如 eth1）在指定子网内的双向 TCP/UDP 连通性，不是简单 ping 通就行。它会尝试绑定私网 IP 发起连接，并校验 MTU、路由表、防火墙策略是否允许该子网内任意端口通信。典型错误是 PRVF-4657 : Connectivity of subnet "192.168.10.0" 后跟 failed，但 ping -I eth1 node2-priv 却成功。
实操建议：
- 确认
/etc/hosts中每个节点的private IP解析必须唯一且不指向127.0.0.1或公网地址；nslookup node2-priv必须返回私网 IP - 运行
cluvfy comp nodecon -n node1,node2 -verbose查看详细日志，重点找 “Failed to connect using UDP” 或 “sendto: No route to host” - 检查私网网卡是否被多路径或 NetworkManager 干扰：
nmcli device status应显示私网接口为unmanaged；否则执行nmcli dev set eth1 managed no - 临时关闭
firewalld（systemctl stop firewalld）再跑验证——若通过，说明问题出在--add-source规则缺失，而非端口放行
私网连通性验证中 ping -M do -s 失败但普通 ping 正常
这说明链路层不支持巨型帧（Jumbo Frames），而 Oracle RAC 默认期望私网使用 MTU=9000（尤其 19c+）。普通 ping 用 64 字节小包能过，但 ping -M do -s 8972 强制发 9000 字节巨帧并禁止分片，任一环节（网卡驱动、交换机端口、对端 MTU）不匹配就会丢包或返回 !F（fragmentation needed）。
实操建议：
- 先查真实支持能力：
ethtool eth1 | grep "Supports jumbo frames"，若为No，换驱动或禁用巨帧（改回 MTU=1500） - 两端必须统一设置：
ip link set dev eth1 mtu 9000，且所有节点重启前不能只改一个；集群启动后不生效，必须停crs后统一设 - 测试必须带源接口：
ping -M do -s 8972 -I eth1 node2-priv，不指定-I可能走错路由 - 交换机侧需确认端口启用 Jumbo Frame（如 Cisco：
system jumbomtu 9000；HPE Aruba：ip jumbo）
节点间 olsnodes 显示在线但 crsctl check cluster 报 CRS-4639
olsnodes -s -t 只读 OCR 和本地 ohasd 进程，而 crsctl check cluster 依赖完整的 CRS 栈（包括 crsd、cssd、IPC 通信）。报 CRS-4639: Could not contact Oracle High Availability Services 表明集群服务未真正拉起，常见于私网 IPC 层被阻断，即使节点“活着”，也无法组成集群。
实操建议：
- 立刻检查
ps -ef | grep cssd，若无进程或状态为Z（zombie），说明 CSSD 启动失败，大概率是私网不通或共享内存初始化失败 - 查看
$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，搜索IPC SEND timeout或clsssInitNative: connect failed, rc 9—— 这是私网被防火墙拦截的铁证 - 不要只查
firewall-cmd --list-services，它不反映 IP 段规则；必须运行firewall-cmd --zone=public --list-rich-rules看是否有reject source私网段的规则 - SELinux 必须设为 permissive 或关闭：
setenforce 0，并执行setsebool -P oracle_execmem 1，否则cssd无法分配共享内存段
/etc/hosts 解析歧义）都可能让验证工具在不同阶段失败，且错误信息高度相似。动手前先确认私网网段、用户 UID、MTU 值、SELinux 状态这四个变量是否在所有节点完全一致。
