背景说明
三个 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 VIParp缓存表。发现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包
测试参数
说明: 测试主机不是生产环境的,所以IP地址不一致
-
keepalived不含上述两个参数测试结果 切换vip后有发free arp包,后续没有继续发


-
keepalived含上述两个参数测试结果 切换vip后有发free arp包,后续继续发free arp数据包



测试结果:配置上两个参数会持续发送free arp包的