vip漂移失败主因是未启动成功，状态为offline或intermediate即证实；首要检查ora.net1.network是否online，其次验证usr_ora_if是否指向公网网卡、交换机port security是否拦截新mac、节点间网卡名是否完全一致，并通过ip addr show和ip neigh show确认真实绑定状态。
VIP漂移失败，90%以上情况根本不是“漂移逻辑出错”，而是VIP压根没启动成功——ora.nodeX.vip状态为OFFLINE或INTERMEDIATE就是最直接证据。
检查ora.net1.network是否ONLINE
VIP强依赖网络资源ora.net1.network（或类似命名），它一挂，VIP连进程都不会拉起。
- 执行
crsctl stat res -t | grep network，确认ora.net1.network状态是ONLINE；若为OFFLINE，先查默认网关：route -n | grep '^0.0.0.0' - 没输出？补网关：
ip route add default via <gateway_ip> dev <public_if></public_if></gateway_ip>；有输出但不通？用ping -c 3 -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必须绑定在公网网卡上，但USR_ORA_IF一旦包含私网口名（如eth1），racgvip就会把地址绑到私网口，客户端完全不可达。
- 查当前配置：
crs_stat -p ora.node1.vip | grep USR_ORA_IF，输出类似USR_ORA_IF=eth0|eth1 - 编辑配置文件，**严格删掉所有非公网网卡名**，只保留一个（如
USR_ORA_IF=eth0）；导出→修改→重载：crsctl replace resource ora.node1.vip -f -p /tmp/vip.cap - 重启VIP后，用
ip addr show确认VIP出现在eth0（或你指定的公网口）下，且ethtool eth0显示Link detected: yes
排查交换机Port Security拦截新MAC
VIP漂移后使用目标节点网卡的MAC地址，若交换机启用Port Security且未放行该MAC，ARP响应会被丢弃，现象是ping不通、TCP连接超时。
- 在目标节点执行
ip link show <public_if></public_if>，确认接口UP且无NO-CARRIER；ethtool <public_if></public_if>中Link detected必须为yes - 登录交换机，查该端口MAC表：
show mac address-table interface Gi1/0/5，确认新节点MAC已学习；再查安全策略：show port-security interface Gi1/0/5 - 若
Security Violation Count > 0或Security Action为shutdown，需在交换机侧放行目标节点MAC或关闭Port Security
确认节点间公网网卡名完全一致
Oracle RAC硬性要求所有节点的public网卡设备名必须字面一致，否则srvctl start vip直接报错退出，VIP根本不会尝试启动。
- 各节点执行
$GRID_HOME/bin/oifcfg getif，对比输出是否完全相同；常见不一致场景：节点1用enp0s3，节点2用ens192 - 修复方式不是改RAC配置，而是统一底层命名：Linux下靠
/etc/udev/rules.d/70-persistent-net.rules绑定MAC与名称；AIX下需核对/etc/path_to_inst中驱动实例顺序 - 别信“通配符能绕过”——即使
root.sh跑完，后续srvctl add vip或监听器注册必失败
真正容易被忽略的是：看到crsctl stat res -t里ora.nodeX.vip显示ONLINE，不代表VIP已真实绑定到网卡。必须用ip addr show和ip neigh show交叉验证，否则所有日志和状态都是假象。
