Keepalived 同网段 virtual_router_id 冲突导致丢包问题处理
问题背景
在同一网段内部署了多套 Keepalived，分别给不同业务提供 VIP（如 Harbor、k8s API ），此次丢包也是请求k8s 服务发现异常。
异常现象
表现为：
- VIP 访问 一会儿通一会儿不通
- 间歇性丢包
- curl / 请求偶发失败
- TCP 连接莫名断开
- 客户端 ARP 表中 VIP 对应的 MAC 地址反复变化
- keepalived 日志疯狂切：
Entering MASTER STATE/Entering BACKUP STATE
开始以为是跨了内网网段，通过安全设备拦截导致
问题原因
Keepalived 基于 VRRP 实现高可用。
在 VRRP 中：
virtual_router_id（VRID）是唯一标识一个 VRRP 组的关键字段- VRRP 只根据 VRID 判断是否属于同一组
- 不区分 VIP，也不依赖 router_id
当同一网段内存在多个 Keepalived 实例，并且使用了相同的 virtual_router_id（都使用 51默认参数）时，会发生以下问题：
- 不同业务的 VRRP 实例被识别为同一组（串组）
- 多个节点参与同一组的 MASTER 选举
- MASTER 状态频繁切换
- 多个节点同时发送 Gratuitous ARP（GARP）
- 客户端和交换机 ARP 表不断刷新（ARP 抖动）
因此就出现了访问k8s的vip出现丢包，连接异常、中断情况，这应该是因为流量被转发到错误节点导致。
排查过程
抓取 VRRP 报文：tcpdump -i <网卡> vrrp，比如我的网卡是enp0s11 ，tcpdump -i enp0s11 vrrp
同一网段存在多个节点发送 VRID 为 51 的 VRRP 报文
也可使用arp -an | grep <VIP>查看 vip 地址的 MAC 地址是否频繁变化。
检查 Keepalived 配置，发现多套业务配置中均使用virtual_router_id 51，确认存在 VRID 冲突。
解决措施
对Keepalived 实例进行梳理，确保同一网段内 virtual_router_id不重复（修改默认virtual_router_id 51）
本次问题根因是：同一网段内多个 Keepalived 实例使用相同 virtual_router_id，导致 VRRP 组冲突，从而引发 ARP 抖动和丢包问题。
教训经验
- virtual_router_id 范围为
1～255 - 同一网段内必须唯一
- Keepalived 不会自动检测冲突
- 一旦冲突，影响是网络级的，而不是单点服务问题