用户报告问题，说在虚拟机里面启动的 Keepalived 有脑裂问题，一启动就开始脑裂了。
Keepalived1 是一个基于 LVS 的负载均衡和高可用框架。负载均衡主要是通过 VRRPv2 协议来实现的。VRRP 协议2在这个博客中介绍过，主要场景是两个路由器可以通过 VRRP 协议来协商出来一个 master，对外提供服务，当 master 挂的时候，slave 会成为 master 继续提供服务。
VRRP 的全称是 Virtual Router Redundancy Protocol，Keepalived 可不是 router，为什么用这个协议呢3？简单来说，Keepalived 要提供的是一个高可用的 VIP 服务，而 Virtual Router 本质上也是一个 VIP 来给其他的 Host 当作网关，这样一想，就很合理了。
Keepalived 实例之间无法达成一致，肯定是 VRRP 协商失败，而 VRRP 又是机器简单的协议，只有一种包的类型。出现 2 个 master 节点，那就肯定是 slave 的节点收不到 master 的 VRRP 协议包，认为 master 挂了，所以站出来当 master。
首先，用 tcpdump 检查了一下两个 keepalived，确实都在发送 VRRP 的包。而且VRRP 包的内容，如 auth，组 id，权重等，都正确。并且都只看得到自己发送出去的包，无法收到对方的包。
那接下来就来排查为什么这个包无法发送给 VRRP 的 slave。
虚拟机环境的网络简化如下。
这个图看起来复杂，其实逻辑很简单。物理机 Host 使用 bonding 连接交换机，在 bond0 接口上配置 VLAN 封装，和交换机做 trunking，这一层对物理机内的网络使用几乎是透明的。然后虚拟机内网络使用 TAP4，所有 VM 内 eth0 发送的包会出现在 macvtap1 上，然后从 Host 的 bond0.1000 出去。 macvtap 其实就是 TAP 设备加上一个 bridge5，macvtap 基于 macvlan driver，使用一个 module 解决了原来 TAP + Bridge 的工作。
下一步就是定位 VRRP 包丢在了哪里，虽然涉及的网络 interface 很多，但是一个一个来排查就行了。首先给这个网络做了个简单的体检套餐，发现 ICMP 还是 TCP 都是一点问题没有，只有 VRRP 协议有问题。VRRP 协议是基于组播 Multicast 的，直觉上觉得可能是什么 ACL 把组播网络给 DROP 了。
从 Keepalived 发包的实例开始抓包，下一步直接抓发包的物理机接口 eth0 （二分查找定位么），确认 VRRP 正确发出去了，然后去收包的物理机上抓 eth0，也收到了，直接排除了交换机的问题。再抓 bond0.1000 接口，也抓得到，排除了 bonding 和 VLAN 问题。
下一步是 [email protected]，也抓得到，然后去收包的 VM2 抓包 eth0，抓不到。那丢包就发生在 macvtap1 -> eth0 中。感觉已经接近真相了！
实际上并没有……
定位到这里之后，后面花了几个小时来研究为什么 macvtap1 的包没有转发到 eth0 中。
期间研究了 macvtap 设备的原理，libvirt 相关的文档，中间还有 chatGPT 这个半吊子瞎出主意，甚至把相关的 sysctl 参数都看了一遍，rp_filter 和 xx_forwarding 之类的，仍然没有解决问题。这些没有用的排查就不记录了。
物理机的 macvtap 的 TAP 设备是由 qemu libvirt 接管的，负责转发到虚拟机中去。在研究 libvirt 和 multicast 流量的时候，发现了这个问题和回答6，虽然没有直接解决我的问题，但是感觉脑中一道闪电划过，有一个重要的本质问题被我忽略了——VRRP 是组播网络！
单播是点对点发，广播是点对所有点群发，组播的特点是点对多点群发，「多点」指的是哪些点呢？怎么知道多点包括了哪些点呢？本质的原理是「订阅」，订阅了特定流量则会收到，如果不订阅，则收不到。
在网络上，多个设备之间订阅组播是通过 IGMP 协议7实现的。在同一个设备上，就是设备自己的实现了。
有了这个想法之后，我马上在 VM 中和 Host 中运行了 ip maddr show dev 命令进行验证。结果如下。
这条命令的含义是，列出来当前这个接口订阅的组播流量。通过结果可以看到，在 VM 中订阅了 VRRP 协议规定的组播地址，但是在物理机的 macvtap 接口上，就没有订阅这个地址。所以物理机的接口在收到发给 224.0.0.1 的 VRRP 流量之后，会认为当前这个接口没有订阅过这个组播，所以不需要这些流量，直接忽略。这是组播协议预期的工作方式，所以当我在排查接口的丢包参数的时候，都没有发现什么异常，因为这不算做是丢包吧，而算作是正常的处理方式。
那么为什么会出现这种情况呢？
按照组播协议的工作方式，当需要组播流量的时候，需要向操作系统通过 syscall 来发出「订阅」8，因为协议是由操作系统来处理的。但是我们这里存在 2 个操作系统，VM 是一个操作系统，Host 是一个操作系统。如上图所示，虽然 VM 知道订阅了这个组播地址，但是 Host 操作系统并不知情，两个系统是隔离的。所以当 Host 收到组播流量的时候，直接忽略了。
解决办法是，对接口设置 ip link set dev macvtap8 allmulticast on，意思是告诉接口，把所有的 multicast 都给收了，这样 VM 内的接口决定处理还是忽略，就正常了。(libvirt 也有 trustGuestRxFilters9 的配置选项）
VRRP 脑裂问题需要避免，在物理网络中，网关之间的 vrrp keepalive 会使用专用的 keepalive 线路，并且多条物理线路做 LACP 高可用。
- https://keepalived.readthedocs.io/en/latest/introduction.html ↩︎
- 数据中心网络高可用技术之从服务器到网关：首跳冗余协议 VRRP ↩︎
- Keepalived 的系统设计：https://keepalived.readthedocs.io/en/latest/software_design.html ↩︎
- TAP 设备在 VPN 和虚拟机网络中比较常见：https://en.wikipedia.org/wiki/TUN/TAP ↩︎
- https://virt.kernelnewbies.org/MacVTap ↩︎
- https://superuser.com/questions/944678/how-to-configure-macvtap-to-let-it-pass-multicast-packet-correctly ↩︎
- https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol ↩︎
- 如何使用组播的教程 https://tldp.org/HOWTO/Multicast-HOWTO-6.html ↩︎
- https://libvirt.org/formatnetwork.html ↩︎