主备切换后业务不通但VIP已漂移、接口正常，大概率是ARP缓存未刷新导致断流；需验证客户端可ping通VIP但TCP连接超时、下游设备ARP表仍为旧MAC、新主发免费ARP后通信恢复等现象，并检查Keepalived notify_master脚本、VRRP设备免费ARP配置及下游ARP老化与同步机制。

主备切换后业务不通，但VIP已成功漂移、接口状态正常——大概率是ARP缓存未及时刷新导致的“断流”。这不是设备没切成功，而是下游设备（尤其是网关或相邻交换机）仍把旧MAC地址绑在VIP上，发来的数据包被错误转发或丢弃。

确认是否为ARP缓存问题

先验证现象是否匹配典型ARP缓存滞后特征：

• 主备切换后，客户端能ping通VIP，但无法建立TCP连接（如SSH、HTTP超时）；
• 在网关或核心交换机上执行display arp | include VIP（华为）或show arp | grep VIP（思科），发现VIP对应的是原主设备的MAC，而非新主设备的MAC；
• 在新主设备上执行arping -I eth0 -c 3 -s VIP 网关IP，若网关响应且后续通信恢复，基本可锁定问题；
• 抓包观察：在客户端或网关侧用Wireshark过滤arp && ip.dst == VIP，若持续收到针对VIP的ARP请求但无稳定应答，说明下游未学习到新MAC。

检查主备设备的ARP通告行为

VRRP主备切换本身不自动触发ARP刷新，需依赖配置显式驱动：

• Keepalived中必须配置notify_master脚本，在升主时主动向网关发送免费ARP（Gratuitous ARP）；
• 脚本内容应类似：/sbin/arping -I eth0 -c 3 -s VIP 网关IP &>/dev/null，注意指定正确网卡和网关IP；
• 检查脚本权限（需可执行）、路径是否正确、是否被SELinux或systemd限制执行；
• 华为/华三等交换机作为VRRP Master时，需确认vrrp vrid x virtual-ip x.x.x.x send-gratuitous-arp已启用（默认部分型号关闭）。

排查下游设备ARP表老化与同步机制

即使主设备发了免费ARP，下游设备也可能因策略未更新：

• 查看网关ARP表项状态：arp -a（Linux）或display arp（交换机），确认VIP条目是dynamic还是static——静态条目不会被免费ARP覆盖；
• 检查ARP老化时间：cat /proc/sys/net/ipv4/neigh/eth0/base_reachable_time_ms（Linux），若设得过大（如>300000ms即5分钟），会导致旧条目长期滞留；
• 堆叠/集群设备需确认主备切换后ARP/MAC表是否完成同步：部分设备需手动开启arp synchronization enable或调整同步周期；
• 防火墙或安全网关可能拦截免费ARP报文，需检查安全策略是否放行类型为0x0806（ARP）的二层广播帧。

临时验证与快速恢复手段

用于定位和应急，不建议长期依赖：

• 在网关设备上手动刷新：执行arp -d VIP（Linux）或reset arp all（华为）强制清除条目，触发重新学习；
• 在新主设备上补发一次免费ARP：arping -U -I eth0 VIP（-U表示Unsolicited）；
• 客户端侧执行arp -d VIP并立即ping VIP，促使本地重学MAC；
• 若频繁发生，可在网关侧对VIP做静态ARP绑定：arp -s VIP 新主MAC，但需确保MAC长期稳定（如使用虚拟MAC或vrrp_mac_addr配置）。