先排查交换机ARP表未刷新，再检查内核arp_ignore/arp_announce参数、Keepalived GARP广播配置、防火墙对VRRP/ARP拦截及VIP是否真实绑定网卡。
当Keepalived完成VIP漂移后，新主节点虽已绑定虚拟IP并运行服务，客户端却仍无法建立连接，常见原因并非服务本身异常，而是网络层关键状态未同步。以下是解决此问题的步骤：
一、检查交换机ARP表是否刷新
新主节点接管VIP后，若交换机ARP缓存中仍映射VIP至旧主节点MAC地址，则所有入向流量被错误转发至下线设备。该现象在Cisco、华为、Juniper等主流交换机上普遍存在，因其ARP老化时间远长于Keepalived默认GARP广播频次。
1、登录核心交换机，执行命令查看VIP对应ARP条目：display arp | include
2、确认输出中MAC地址是否为新主节点网卡实际MAC（可通过ip link show dev eth0 | grep link/ether获取）
3、若MAC仍为旧主节点，手动清除该ARP项：reset arp dynamic ip
4、在新主节点执行arping强制刷新下游设备缓存：arping -I eth0 -c 3 -s
二、验证内核ARP响应参数配置
Linux内核默认抑制非本地接口绑定IP的ARP响应行为，导致即使VIP已成功添加，网关及客户端仍无法学习到其MAC地址。必须显式启用VIP的ARP宣告能力。
1、检查当前arp_ignore值：cat /proc/sys/net/ipv4/conf/all/arp_ignore
2、检查当前arp_announce值：cat /proc/sys/net/ipv4/conf/all/arp_announce
3、临时生效设置（所有节点执行）：echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore && echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
4、持久化写入sysctl.conf：echo "net.ipv4.conf.all.arp_ignore = 1" >> /etc/sysctl.conf && echo "net.ipv4.conf.all.arp_announce = 2" >> /etc/sysctl.conf && sysctl -p
三、确认Keepalived GARP广播机制是否激活
Keepalived默认仅在主备切换瞬间发送一次Gratuitous ARP报文，极易因网络拥塞或交换机处理延迟而丢失。缺乏重试机制将导致ARP表长期滞留旧条目。
1、编辑/etc/keepalived/keepalived.conf中vrrp_instance段
2、添加GARP刷新参数：garp_master_refresh 10
3、添加GARP刷新次数限制：garp_master_refresh_repeat 3
4、重启服务使配置生效：systemctl restart keepalived
四、排查防火墙对VRRP及ARP报文的拦截
VRRP协议使用IP协议号112，非UDP/TCP端口；而GARP属于二层ARP帧，部分防火墙策略可能无差别DROP所有非标准协议或未授权ARP响应，造成心跳中断与宣告失败。
1、检查iptables规则是否放行VRRP：iptables -L INPUT -n | grep 112
2、若无匹配项，添加显式允许规则：iptables -I INPUT -p 112 -j ACCEPT
3、检查firewalld服务是否启用：firewall-cmd --state
4、启用VRRP富规则：firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" accept'
五、验证VIP是否真实绑定至网卡
Keepalived进程运行正常不等于VIP已成功注入内核路由表。常见于network namespace隔离、SELinux策略拦截、vrrp_script执行失败或interface名称配置错误等场景。
1、在新主节点执行：ip addr show dev eth0 | grep
2、若无输出，检查Keepalived日志定位绑定失败原因：journalctl -u keepalived -n 50 --no-pager | grep -i "error\|fail\|bind"
3、确认配置中interface字段与真实网卡名一致：ip link show | awk -F': ' '{print $2}' | grep -v "^$"
4、手动测试VIP绑定能力：ip addr add
