为何Oracle RAC的私有网卡必须禁用NetworkManager服务？

必须停用NetworkManager，否则其ARP接管与HAIP冲突导致心跳丢失、haip状态异常；还需固定网卡名、调rp_filter为2、清除私网卡默认网关。

NetworkManager 会劫持 HAIP 的 ARP 行为

oracle rac 私网依赖 haip（high availability ip）实现双网卡冗余，而 haip 是 oracle 自己管理的虚拟 ip，运行在 eth2、eth3 等物理接口上，通过内核级 arp 广播宣告自己“在线”。networkmanager 默认会对所有已配 ip 的接口主动发送 gratuitous arp，并接管 arp 表维护逻辑——这与 haip 的行为冲突，导致节点间反复丢失心跳或 ora.cluster_interconnect.haip 状态在 offline/intermittent 之间跳变。

实操建议：

• 必须在所有节点执行 systemctl stop NetworkManager 和 systemctl disable NetworkManager
• 确认无残留进程：ps -ef | grep NetworkManager，有则 kill -9 干净
• 检查 /etc/sysconfig/network-scripts/ifcfg-eth2 中是否含 NM_CONTROLLED=no（仅辅助，不能替代停服务）
• 重启 CRS 前用 ip addr show 验证 HAIP 是否出现在正确接口（如 eth2:1），而非被 NM 挪到 bond0 或其他虚拟设备上

私网网卡名不一致时 NM 会固化错误映射

克隆虚拟机后，udev 可能将同一块网卡识别为 enp0s8，而另一节点是 ens33；NetworkManager 会基于当前名称生成连接配置并写入 /etc/NetworkManager/system-connections/。一旦启用，它会在每次网络重载时强制恢复该名称绑定，导致 oifcfg getif 在两节点输出不同接口名，触发 PRVG-11050 错误。

实操建议：

• 禁用 NM 后，改用传统 network.service 管理，再统一用 udev 规则固定网卡名为 eth2/eth3
• 编辑 /etc/udev/rules.d/70-persistent-net.rules，只保留目标 MAC 对应行，并设 NAME="eth2"
• 同步修改 ifcfg-eth2 中的 DEVICE=eth2 和 HWADDR 字段，确保与真实 MAC 一致
• 执行 udevadm control --reload-rules && udevadm trigger --subsystem-match=net 生效，无需重启

rp_filter + NM 共同作用会导致私网包被丢弃

RAC 私网通信使用 UDP 12599 端口，且常走多路径（如 eth2 收、eth3 发）。Linux 默认 rp_filter=1（严格反向路径检查），要求“从 eth2 进来的包，其源 IP 必须能通过 eth2 返回”——但 HAIP 的路由策略可能让回包走 eth3，NM 又会动态刷新路由表，加剧路径不一致。结果就是 cssd 日志频繁出现 clsc_sendmsg: sendto() failed with errno=113（no route to host）。

实操建议：

• 禁用 NM 后，手动设置 sysctl -w net.ipv4.conf.eth2.rp_filter=2（宽松模式）
• 写入 /etc/sysctl.conf 持久化：net.ipv4.conf.eth2.rp_filter = 2、net.ipv4.conf.eth3.rp_filter = 2
• 注意：不能只设 all 或 default，RAC 要求按接口精确控制
• 验证：sysctl net.ipv4.conf.eth2.rp_filter 输出应为 2

默认网关错绑到私网卡上

当 NetworkManager 被禁用后，系统退回到传统 network.service，此时若多个网卡都配置了 GATEWAY（比如在 ifcfg-eth1 和 ifcfg-eth2 中都写了），network.service 会把最后一个加载的网卡的网关设为全局默认路由。若私网卡 eth2 的配置文件里误写了 GATEWAY=10.10.20.1，route -n 就会出现 0.0.0.0 → 10.10.20.1 经由 eth2，导致所有跨网段流量（包括公网访问、存储挂载）全被导向私网，业务连不上数据库。

实操建议：

• ifcfg-eth2 和 ifcfg-eth3 中绝对不要出现 GATEWAY 行
• 只在公网卡（如 ifcfg-eth0）中配置 GATEWAY，且确保其 ONBOOT=yes
• 执行 ip route del default 清空现有默认路由，再 systemctl restart network 让配置生效
• 验证：route -n | grep '^0.0.0.0' 输出的 Iface 列必须是公网卡（如 eth0）

真正要命的不是 NetworkManager 本身，而是它和 RAC 底层机制（HAIP、udev、rp_filter、路由决策）之间的隐式耦合。哪怕只在一个节点漏掉 systemctl disable NetworkManager，后续所有检查（cluvfy、crsctl check cluster）都可能通过，但集群上线后某次网卡重载就会突然失联——这种问题很难复现，也最难排查。