背景说明

三个 keepalived 服务组成一个高可用环境。风和日丽的下午突然通知某个生产环境 vip 不通，使用承载 vip 的主机测试服务是正常。进而推断 keepalived 导致的问题。。。

三个主机IP地址分别是：x.x.3.17 、 x.x.3.18、x.x.3.19。
VIP地址是: x.x.3.20，该地址绑定在 x.x.3.18 主机上

排查过程

三台主机 ping VIP ，有个两台主机不通(x.x.3.17, x.x.3.19)，只有一台(x.x.3.18)承载VIP主机正常
三台主机查看防火墙都是没有问题的
(x.x.3.17, x.x.3.19)主机查看 arp -n | grep VIP arp缓存表。发现vip对应的mac地址(x.x.3.19主机)不对。这个mac所在主机是没有 VIP 地址的，所以 ping vip 不通
(x.x.3.17, x.x.3.19)主机删除arp缓存表 arp -d VIP，抓包显示很快 x.x.3.19 主机回包
再次查看 arp -n | grep VIP ，发现还是没有学习到正确的mac。
【临时修复方法】手工设置arp缓存表 arp -s x.x.3.20 fa:16:3e:09:c8:8c
推测与(主机\交换机)有关，后续找主机同事一起排查。主机是openstack虚拟机，从宿主机上面看到 VIP 绑定在 x.x.3.19 主机上
重启keepalived恢复正常。基本上确认了，Free arp 包在底层没有收到引起 vip 还记录在旧主上。
主机同事反馈 keepalived 服务建议设置上 grap_master_delay 和 garp_master_refresh 参数。持续发生 Free arp 包