主备切换后业务不通但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配置）。
