vip不漂移主因是rac未触发failover：ifconfig down网卡属管理操作，非故障；真实断网需通过心跳超时（如丢udp 12345包）或启用ping target探测远端可达性来验证。
断网测试中vip不漂移，大概率不是oracle没检测到网络故障，而是集群根本没把这次“断网”识别为需要触发failover的事件——它压根没进入故障判定流程。
为什么ifconfig down公网网卡后VIP纹丝不动
Oracle RAC默认只检查网卡是否UP、IP是否配置，并不主动探测网卡能否通外网。直接执行ifconfig eth0 down，虽然物理链路断了，但Clusterware看到的是“网卡已关闭”，这属于预期中的管理操作，不会触发驱逐或VIP漂移。
- 它和真实线缆拔掉/交换机端口down有本质区别：后者网卡仍UP，只是收不到包，cssd才会走心跳超时逻辑
-
srvctl stop nodeapps -n或crsctl stop crs这类显式停止命令，也会抑制VIP漂移，因为资源状态被标记为“人为停用”而非“故障” - 验证方式：在节点上执行
oifcfg getif，确认public网卡名是否仍在输出中；若已消失，说明Clusterware已将其从心跳路径中剔除，自然不判故障
虚拟机环境里拔网线为啥也不漂移
VMware/KVM等虚拟化平台在宿主机侧拔掉vNIC物理连线时，客户机操作系统通常收不到链路状态变化通知（carrier down），ethtool eth0仍显示“Link detected: yes”，网卡持续UP且能ARP、ping通本机——RAC就认为“一切正常”。
- 这是12c引入
ping target功能的根本原因：靠主动探活远端地址来补足本地检测盲区 - 检查是否启用：
srvctl config network -k 1，看输出里是否有Ping Targets字段 - 未启用时，即使你拔了线、客户端连不上VIP，
crsctl check cluster仍返回SUCCESS，ocssd.log里也看不到missed heartbeat
misscount设得太大会掩盖真实断网
哪怕心跳真的丢了，如果misscount值过大（比如设成120），而你的断网测试只维持了20秒，cssd会安静等待满120秒才启动驱逐，期间VIP完全不响应。
- 查当前值：
crsctl get css misscount - 默认30秒（11gR2+），虚拟化环境建议45–60，但绝不能盲目堆高；超过90秒基本失去快速故障转移意义
- 注意：该参数必须所有节点一致，否则集群起不来；修改后需
crsctl stop crs && crsctl start crs全量重启 - 别只盯
misscount——disktimeout必须大于它，否则磁盘心跳永远赶不上网络心跳超时，节点反而更容易被误驱逐
真正该测的不是“断网”，是“心跳不可达”
想验证VIP漂移机制是否有效，绕过网卡层，直接模拟心跳失败更可靠：
- 在目标节点防火墙里丢弃发往其他节点public IP的UDP 12345端口（cssd心跳端口）：
iptables -A OUTPUT -d <other_node_public_ip> -p udp --dport 12345 -j DROP</other_node_public_ip> - 或临时重定向voting disk路径（需ASM未mount），让磁盘心跳超时，触发更底层的驱逐
- 观察
$GRID_HOME/log/<host>/cssd/ocssd.log</host>，搜索missed heartbeat和node eviction initiated，这才是VIP开始漂移前的真实信号 - 漂移发生后立刻在新节点跑
arping -U -c 3 -I eth0 <vip_address></vip_address>，否则客户端可能因ARP缓存旧MAC而连不上
断网测试失效，往往是因为测试方式和RAC故障检测机制错位。与其反复拔线，不如直击心跳路径，再配合ping target和ARP刷新，才能让VIP在真实故障中稳稳接住流量。
