有件事你可能不太清楚：在过去多个排障群里，关于“为什么VIP不漂移”的咨询案例中，经过层层排查，最终都指向同一个根本原因——Oracle RAC集群根本没有将那次事件认定为“故障”。
在断网测试过程中，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认为“一切正常”，不会触发任何动作。
- 这正是Oracle 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-p udp --dport 12345 -j DROP - 或者临时重定向voting disk路径（需ASM未mount），让磁盘心跳超时，触发更深层的节点驱逐。
- 观察
$GRID_HOME/log/，搜索/cssd/ocssd.log missed heartbeat和node eviction initiated，这些才是VIP开始漂移前的真实信号。 - 漂移发生后，立即在新节点上执行
arping -U -c 3 -I eth0，否则客户端可能因ARP缓存中保留着旧的MAC地址而无法连接。
断网测试失效的根源，往往在于测试方法与RAC故障检测机制之间存在错位。与其反复进行拔线操作，不如直接切入心跳路径，再配合ping target和ARP刷新，才能确保VIP在真实故障发生时稳稳承接流量。
