为什么Oracle RAC中的VIP不能在节点间正常进行漂移

Oracle RAC中VIP无法漂移绝大多数情况是根本未启动，而非漂移失败；ora.nodeX.vip状态为OFFLINE或INTERMEDIATE即证实未绑定，主因包括ora.net1.network offline、USR_ORA_IF指向私网网卡、交换机port security拦截新MAC、网卡名不一致等。

oracle rac中vip无法漂移，绝大多数情况不是“漂移失败”，而是根本没启动或压根没尝试漂移——ora.nodex.vip资源状态为 offline 或 intermediate 就是铁证。

ora.net1.network offline 直接拦停 VIP 启动

VIP 资源强依赖 ora.net1.network（或类似命名的网络资源），它一 offline，VIP 连进程都不会拉起。别急着查漂移逻辑，先确认这个上游资源是否活着：

• 执行 crsctl stat res -t | grep network，看 ora.net1.network 状态是否为 ONLINE
• 若为 OFFLINE，检查该节点是否配了默认网关：route -n | grep '^0.0.0.0'；没输出就补上，有输出则用 ping -I <public_if><gateway_ip></gateway_ip></public_if> 验证可达性
• 常见陷阱：多网卡环境漏配网关，或网关在另一个子网但没加静态路由
• 更隐蔽的问题：若 ora.cvu 资源仍 online 且依赖公网，CRSD 会卡在“等待所有依赖资源停止”阶段，导致 ora.net1.network 无法重启——此时需先 srvctl stop cvu，再 crsctl start res ora.net1.network

USR_ORA_IF 指向私网网卡导致 VIP 绑定错位

VIP 必须绑定在公网网卡上，但 USR_ORA_IF 属性一旦包含私网口名（如 eth1），racgvip 就会把地址绑到私网口，现象是 ip addr show 里 VIP 出现在 eth1 上，客户端完全无法访问：

• 查当前配置：crs_stat -p ora.node1.vip | grep USR_ORA_IF，输出类似 USR_ORA_IF=eth0|eth1
• 必须严格删掉所有非公网网卡名，只保留一个——比如 USR_ORA_IF=eth0
• 修改方式：导出配置 crs_stat -p ora.node1.vip > /tmp/vip.cap → 编辑文件 → crsctl replace resource ora.node1.vip -f -p /tmp/vip.cap
• 验证：重启 VIP 后，ip addr show 中 VIP 必须出现在 eth0（或你指定的公网口）下，且该口 ethtool eth0 显示 Link detected: yes

交换机端口安全策略拦截新节点 MAC 地址

VIP 漂移后使用的是目标节点网卡的 MAC 地址，若交换机启用了 port security，而该 MAC 未被放行，ARP 响应会被丢弃，客户端 ping 不通、TCP 连接超时：

• 在目标节点执行 ifconfig eth0，记下 ether 后的 MAC 地址
• 登录交换机，查该物理端口的 MAC 表：show mac address-table interface Gi1/0/5（替换为实际端口），确认新节点 MAC 是否存在
• 查端口安全状态：show port-security interface Gi1/0/5，若 Security Violation Count > 0 或 Security Action 是 shutdown，问题基本锁定
• 临时解决：在交换机上 no switchport port-security；长期方案：将所有 RAC 节点公网网卡 MAC 加入交换机白名单

网卡名不一致让 srvctl 直接拒绝启动 VIP

Clusterware 要求所有节点的公网网卡设备名**字面完全一致**，哪怕只是 enp0s3 和 ens192 的差异，srvctl start vip 就会报 invalid interface "ens192" 并退出：

• 逐节点执行 $GRID_HOME/bin/oifcfg getif，对比输出是否一字不差
• 真实接口名以 ip -br a 或 ls /sys/class/net/ 为准，别信旧文档或 ifconfig 别名
• Linux 下统一命名靠 /etc/udev/rules.d/70-persistent-net.rules 绑定 MAC 与名称；AIX 下需核对 /etc/path_to_inst 中驱动实例顺序
• 注意：虚拟化平台（VMware/KVM）和云环境（AWS/阿里云）常因驱动不同导致网卡名天然不一致，必须手动对齐

真正难排查的点往往藏在底层：你以为 VIP 漂过去了，其实它连操作系统网卡都没绑上；你以为交换机没问题，其实 port security 正静默丢包；你以为网关 ping 得通，但 racgvip 检测的是 RX 包增量，不是 ICMP 回包本身。