因为arp 问题导致的vip 故障与解决方案

这几天进行了关于vip 方面的检测的 测试，

遇到了一个奇怪的问题，vip 服务正常，数据库可以通过vip访问，但是从库在ping vip 的时候，却告警ping 不通，

出现的次数也不多，每天有2,3次的样子，检测过程经过了容错包装，也不至于会导致系统误切换。

但是还是搞清楚，心里才踏实。 

联合网络做了些分析： 

经过查看当时的日志还是发现了一些端倪的： 

从机会通过arping 去确认vip 是否存活， 然后我们就在这里发现了问题了。 


这套设备是启动了双网卡的，一个工作网络，一个是心跳网络

最后发现 在ping 之前发出的那个arp 相应包，是不是工作网卡的mac 地址

而是心跳 网卡的mac 地址

然后ping 完后，就变工作网卡的mac 地址了。 



在网络同事的帮助下，分析了原因： 


默认情况，linux 的arp 响应是出在混杂模式的， 
主机默认是开启arp 混杂模式的，
就说这台机器上如果有多个网卡启动，那么在混杂模式下，我这个网卡收到arp 询问的时候，如果如果这台机器上配置了对应的ip 但不是配置我当前的网卡上，那么这个网卡还是可能会响应arp 询问包，把自己的arp 回给对方。

这个情况下，就导致对方询问的arp 不是目标ip 所在的网卡。 

从日志里也得到了证实， 我们从库会通过arp 广播来确定确定vip 是否在运行，这个时候某些情况下，我们接受的arp 回应是主库的另外一个网卡的arp 不是vip 所在网卡的arp ，在接下来的ping 的检测，因为在不同的网段，arp 表中标记的arp 跟vip 不在同一个子网里，导致ping 不通。


这样就解释的通，为什么ping 不同vip 

解决方案： 

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2


这两个参数写到/etc/sysctl.conf 里面 


怎么生效，就不说了吧？

sysctl  -p 后 

是需要重启网卡生效的 



一般情况下都不太可能用到这种混杂模式的，所以在装机的就处理掉最好，免得梦多。 


祝玩得愉快！！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/133735/viewspace-1182301/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/133735/viewspace-1182301/