keepalived网络配置问题解决过程

今天在处理客户现场的keepalived的问题时，（架构是两个节点使用单播模式进行虚拟IP的绑定和切换），遇到了两台服务器都直接绑定虚拟IP，然后两个节点都直接报广播超时的问题报错信息为：
Sun Nov 26 13:02:39 2023: (VI-SLB) Backup received priority 0 advertisement
Sun Nov 26 13:02:39 2023: (VI-SLB) Receive advertisement timeout

但是两个节点互相使用ping命令又可以正常通，没啥毛病，只是两个节点之间
一直互相收不到另外一台节点的广播信息，然后我们就看了一下这台服务器的网络情况，使用ifconfig命令查看了两台服务器的网络配置，如下图：


之前忘记关注的点，这个ens2f0的网卡根本没有接收和发送包，呜呜呜········

发现节点一的网络一直不断地丢包现象，我们就以为节点一的网络有问题，无法正常接收包，所以才无法正常接收节点二的广播信息，虽然我配置的keepalived.cof的网络延迟高达20秒，还是无法接收，配置如下：

然后我们就让交互的人去现场排查节点1的网络问题，等待了几天，网络还是没有解决，然后 又催促解决keepalived的问题，说现场133服务的网络是正常的，因为pxc都部署在上面，mysql都能正常通行，为啥keepalived不行，肯定是配置有问题，所以我又开始按交付的人说的开始排查134服务器（节点二）的网络配置问题，结果还真发现134服务器的网络有点问题，虽然它没有丢包的现象，但是发现他的ip a命令执行的结果有点奇怪，如下图：

原来是节点二上面的网卡ens2f0本来就处于down的状态，虽然绑定了一个10.101.54.134的IP地址，但是他处于 NO-CARRIED，然后我又上网查了一下， NO-CARRIED状态就是表示网卡已经处于up状态，但是因为物理层的原因导致网络没连接，比如网线没插好之类的。
还可以通过ethtool [网卡名] 进行查看这个网卡的状态，就开始执行命令，结果如下：

排查了半天终于明白了，是交付现场人员把ens2f0网卡对应的网络插口拔掉了，直接查到ens2f1网卡的接口上了，ens2f1网卡和ens2f0 网卡都配置了同样的ip地址，然而我们keepalived的配置还是以前的interface配置项，还是以前的ens2f0，所以节点二服务器上的keepalived把虚拟ip绑定到了ens2f0上，这个也没什么毛病，只是两个节点都收不到各自的广播信息，最后我节点二的把keepalived的配置interface改成了ens2f1，才解决了两变都收不到广播信息的问题，最后终于两个节点，终于只绑定一台为虚拟IP

综合以上经验教训，网络有丢包的现象不一定会影响广播连接的建立，只是会导致虚拟IP一直飘过来票过去的现象，下次一定记得排查两边的网卡配置和网络传输包的数量，不要只看一台的ifconfig，两台的ifconfig都要看