keepalived vip漂移后连接不可用，主因是下游设备arp缓存未更新；需调优内核参数（arp_ignore=1、arp_announce=2）、启用garp重试（garp_master_refresh）并配合notify脚本执行arping强制刷新网关arp表。
Keepalived 或 Clusterware 切换 VIP 后，网关/客户端仍发包到旧 MAC
这不是 Keepalived 没绑上 VIP，也不是 Oracle Clusterware 漂移失败，而是下游设备（交换机、网关、甚至客户端本机）ARP 表里还存着旧节点的 MAC 地址。只要没收到新 ARP 响应，流量就继续往“已下线”的节点送，表现为 ping 得通但数据库连不上、连接超时或被拒绝。
arp_ignore=0 和 arp_announce=0 是默认陷阱
Linux 内核默认允许任何接口响应非本接口绑定 IP 的 ARP 请求。VIP 漂移到新节点后，若未调优内核参数，可能出现两种危险情况：
-
arp_ignore=0：旧节点哪怕已退为 BACKUP，只要 VIP 还在内核路由表中（比如残留配置或未清理干净），它仍会响应 ARP —— 导致“双主应答”，流量分裂 -
arp_announce=0：新主节点发出 ARP 响应时，可能用错源地址（比如从物理 IP 接口发，而非 VIP 所属子网接口），交换机丢弃该报文 - 正确值应为：
arp_ignore=1（只响应目标 IP 真实绑定在该接口上的请求）、arp_announce=2（优先使用与目标 IP 同子网的接口发 ARP） - 必须在
all和具体接口（如ens192）两个层级同时设置，否则云环境或 VLAN 子接口下仍失效
Keepalived 的 GARP 广播太“佛系”，一次失败就放弃
Keepalived 默认只在状态切为 MASTER 的瞬间发 1 次 Gratuitous ARP，不重试、不校验是否被接收。网络抖动、交换机端口安全策略（如 Cisco ip arp inspection）、甚至网卡驱动 bug 都可能导致这次广播静默丢失。
- 必须显式启用重试机制：
garp_master_refresh 10（每 10 秒重发一次）、garp_master_refresh_repeat 3（每次最多发 3 轮） - 更稳妥的做法是配合 notify 脚本，在
notify_master中执行arping -I ens192 -c 5 -s <vip><gateway></gateway></vip>，强制刷新网关缓存 - 注意：
arping的-s参数必须指定 VIP，否则交换机学到的是物理 IP 的 MAC，不是 VIP 的
Oracle RAC 自身 VIP 不走传统 ARP 流程，但 Clusterware 不负责刷下游
Oracle RAC 的 VIP 是由 ora.<nodename>.vip</nodename> 资源动态绑定的，它不依赖 ifconfig 或 ip addr add，也不触发内核标准 ARP 行为。Clusterware 只管把 VIP 绑到网卡、启动监听器，但完全不管交换机或客户端 ARP 表是否更新。
- 这意味着：即使
crsctl stat res -t | grep vip显示 ONLINE，且ping <vip></vip>成功，也不能保证客户端能建连 - 必须手动补上 ARP 刷新动作，尤其在私有云或 VMware 环境中，虚拟交换机 ARP 老化时间常设为 14400 秒（4 小时），远超故障转移容忍窗口
- 别依赖“等一会儿”，生产环境要主动干预：在新主节点执行
arping -I eth0 -c 3 <vip></vip>并用tcpdump -i eth0 arp确认 who-has/tell 报文真实发出且被响应
