VIP漂移后ping通但连接失败，根本原因是交换机ARP表未更新，仍映射VIP至宕机节点MAC，导致TCP请求发往错误地址；crsctl显示ONLINE仅表示CRS完成绑定，不保证二层ARP同步。
为什么VIP漂移后ping通但连接失败
能ping通vip ≠ 数据库可连。vip漂移后，目标节点确实绑定了该ip（ip addr show能看到），但监听器默认只监听本节点的vip和物理ip，不会自动为“接管来的vip”注册服务。所以tcp连接会直接被拒绝或超时，报错ora-12541: tns:no listener。
根本原因不是Oracle没漂移，而是网络层ARP缓存未更新：交换机仍把旧VIP映射到宕机节点的MAC地址，新节点发的ARP广播可能被丢弃、压制，或未被及时学习。
- 现象：从客户端
pingVIP成功，但telnet vip 1521不通；在新节点上执行lsnrctl status，看不到该VIP监听的端口 - 验证命令：
arping -c 3 -I eth0 <vip_address></vip_address>，观察是否收到响应；登录交换机查show arp | include <vip_address></vip_address> - 关键点：ARP表老化时间（常见4小时）远长于VIP漂移时间（2–5秒），导致“地址已迁、MAC未换”状态持续数小时
如何确认是ARP表卡住而非Oracle配置问题
别急着改listener.ora或重启CRS——90%的“VIP不接管”类问题，根源在交换机ARP表。先绕过Oracle，直击网络层：
- 在新接管节点执行：
arping -U -c 3 -I eth0 <vip_address></vip_address>（-U表示主动通告，强制刷新） - 从客户端抓包：
tcpdump -i any host <vip_address> and port 1521</vip_address>，看SYN包是否到达、是否有SYN-ACK返回 - 对比测试：用SCAN IP连接是否正常？如果SCAN能连，基本锁定是单个VIP的ARP/路由问题，而非集群整体故障
- 注意：某些交换机（尤其开启DHCP的汇聚层）会把VIP误判为“冲突IP”，静默丢弃ARP响应，此时
arping返回空或timeout
临时修复与长期规避策略
生产环境不能等4小时ARP老化，必须主动干预。但方案要区分场景：
- 紧急恢复：在新接管节点运行
arping -U -I eth0 <vip_address></vip_address>，再配合交换机侧执行clear arp-cache或针对该IP执行arp -d <vip_address></vip_address> - 防复发：关闭VIP的自动failback（避免反复漂移加剧ARP混乱），设置
ORA_RACG_VIP_FAILBACK=0并重启ora.<nodename>.vip</nodename>资源 - 架构优化：客户端连接串一律用SCAN，而非硬编码VIP；SCAN Listener本身具备跨节点代理能力，对ARP不敏感
- 风险提示：手动修改交换机ARP表需权限，且部分厂商设备（如华为S系列）需同时清
arp和nd（IPv6邻居）表，否则IPv6流量仍走老路径
为什么crsctl stat res -t显示VIP ONLINE却不可用
crsctl stat res -t只说明VIP资源由CRS管理且状态为ONLINE，它不验证三层连通性，更不校验二层ARP映射是否生效。你看到的“ONLINE”仅代表Clusterware完成了IP绑定动作，不代表网络设备已同步该变更。
真正决定可用性的三个断层依次是：OS网卡绑定 → 交换机ARP学习 → 客户端路由可达。任何一个环节卡住，都会表现为“VIP在线但无法建连”。最常被忽略的是第二层——管理员看到ifconfig有VIP、crsctl显示ONLINE，就认为没问题，结果客户端还在往老MAC发包。
下次遇到类似问题，先做arping，再查交换机ARP表，最后才碰Oracle配置。网络层的问题，不该用数据库工具去诊断。
