问题背景

公司内网核心层采用两台三层交换机（下称 CORE-A、CORE-B）做网关冗余：每个业务 VLAN 起一个 VRRP 组，虚拟网关 IP 形如 10.20.x.254，CORE-A 优先级 120 为 Master，CORE-B 优先级 100 为 Backup，并开启 preempt 抢占。两台核心之间跑一条二层 Trunk 互联，VRRP 的 Advertisement 报文（组播 224.0.0.18，协议号 112）就依赖这条 Trunk 在各业务 VLAN 内互通。

上周五晚上，网络组对两台核心之间的 Trunk 链路做过一次「VLAN 修剪优化」——为了收敛广播域，把 Trunk 上放行的 VLAN 列表按「实际使用」重新梳理了一遍。变更窗口内 ping 测正常，就收工了。

故障现象

周一早上 9 点起，陆续有多个部门报障，现象很有迷惑性：

• 用户表现为「一阵一阵断网」：内网系统访问几秒正常、几秒超时，刷新几次又好了；
• 持续 ping 网关 10.20.30.254，丢包呈周期性：连续十几个正常，然后连丢 3~5 个，如此往复；
• 只有部分 VLAN 受影响（VLAN 30、40 的用户段），服务器段 VLAN 10、20 完全正常；
• 接入交换机上没有端口 up/down 日志，链路层看起来一切正常。

最诡异的是：受影响用户 arp -a 查网关 MAC，不同时间点看到的值会变——一会儿是 0000-5e00-011e（VRRP 虚 MAC），行为却像是在两台设备之间来回切。

排查过程

第一步：先看两台核心的 VRRP 状态。

分别登录两台核心查看：

1
2
3
4
5
6
7
8
9

[CORE-A] display vrrp brief
VRID  State    Interface       Virtual IP
30    Master   Vlanif30        10.20.30.254
40    Master   Vlanif40        10.20.40.254

[CORE-B] display vrrp brief
VRID  State    Interface       Virtual IP
30    Master   Vlanif30        10.20.30.254
40    Master   Vlanif40        10.20.40.254

问题一目了然：VLAN 30、40 的 VRRP 组两边都是 Master——典型的双主（脑裂）。而正常的 VLAN 10、20，CORE-B 显示 Backup。这也解释了为什么只有部分 VLAN 受影响。

第二步：确认双主的直接后果。

双主意味着两台核心都认为自己持有虚拟网关，都会用同一个虚 MAC 0000-5e00-011e 对外发 ARP 应答和免费 ARP。在接入交换机上查 MAC 表：

1
2

[ACC-3F] display mac-address flapping record
VLAN 30: MAC 0000-5e00-011e flapping between GE0/0/27 (uplink-to-A) and GE0/0/28 (uplink-to-B), 47 times in 5 minutes

虚 MAC 在通往两台核心的两条上联口之间高频漂移。用户流量一会儿被送往 CORE-A、一会儿被送往 CORE-B，谁的免费 ARP 后到就跟谁走——这正是「周期性丢几个包又恢复」的来源：部分会话的回程路径与去程不一致，且状态在两台设备间来回摇摆。

第三步：查双主的成因——为什么 Backup 收不到 Master 的通告？

VRRP 的机制是：Backup 在 3 个通告周期（默认 3 秒多）收不到 Master 的 Advertisement，就自立为 Master。两边同时 Master，说明 VLAN 30、40 的 VRRP 通告在两台核心之间不通。通告报文走的是核心互联 Trunk 的对应 VLAN，立刻检查这条 Trunk：

1
2
3

[CORE-A] display port vlan Eth-Trunk1
Port         Link Type    PVID    VLAN List
Eth-Trunk1   trunk        1       1 10 20 100

真相大白：周五的「VLAN 修剪」把 Trunk 放行列表改成了 1 10 20 100——VLAN 30 和 40 被剪掉了。变更人梳理"实际使用"时，只统计了跨核心的服务器流量所在 VLAN，漏掉了「用户 VLAN 虽然没有跨核心业务流量，但 VRRP 心跳必须借这条 Trunk 互通」这一层。

第四步：解释「变更当晚正常、周一才爆发」。

变更当晚 ping 测正常并不奇怪：剪掉 VLAN 后 3 秒内 CORE-B 就升为 Master，形成双主。但晚上没有用户流量，双主状态下两台设备各自应答、各自转发，低负载下 MAC 漂移的竞争不激烈，ping 网关基本不丢。周一早高峰用户流量上来，ARP 请求/免费 ARP 频繁、两台核心的应答竞争加剧，MAC 表高频翻动，间歇性丢包才被放大成可感知的故障。

解决方案

止血（5 分钟内）： 在核心互联 Trunk 上把被剪掉的 VLAN 加回放行列表：

1
2

[CORE-A] interface Eth-Trunk1
[CORE-A-Eth-Trunk1] port trunk allow-pass vlan 30 40

VLAN 30、40 的 VRRP 通告恢复互通后约 3 秒，CORE-B 收到 CORE-A（优先级 120）的通告，自动降回 Backup：

1
2
3

[CORE-B] display vrrp brief
30    Backup   Vlanif30        10.20.30.254
40    Backup   Vlanif40        10.20.40.254

接入交换机 MAC 漂移记录停止增长，用户侧 ping 网关连续 10 分钟 0 丢包，故障解除。

加固（当天完成）：

1. 全网核对所有 VRRP 组两端状态，确认无其他 VLAN 存在同类隐患；
2. 在两台核心的互联 Trunk 配置注释中显式标注「本 Trunk 承载全部 VRRP 心跳，修剪 VLAN 前必须核对 VRRP 组列表」；
3. 为 VRRP 状态变化配置 SNMP Trap 上报（vrrpTrapNewMaster），接入网管告警——本次 CORE-B 升 Master 其实周五晚上就发生了，只是没人知道。

根因分析

直接原因：核心互联 Trunk 做 VLAN 修剪时，误将仍承载 VRRP 心跳的 VLAN 30、40 从放行列表剔除，Backup 收不到 Master 通告，超时自立为 Master，形成双主。

深层原因有两点：一是变更影响面评估只看了"业务流量"，没看"协议流量"——VRRP、STP、组播这些控制平面报文对 VLAN 放行的依赖是隐性的，不体现在流量报表里；二是缺少 VRRP 状态监控，双主形成后近 60 小时无人察觉，直到业务高峰把问题放大。

预防措施

1. 变更清单制度：涉及 Trunk VLAN 放行列表的变更，必须比对该链路承载的 VRRP/HSRP 组、STP 实例、组播组清单，逐项确认后方可执行；
2. 监控补位：所有 VRRP 组状态纳入网管轮询，Master 切换、双 Master 检测（同一 VRID 两端同时 Master）触发即时告警；
3. 变更后验证脚本化：不能只 ping 网关，加一条「两端 display vrrp brief 状态比对」——一端 Master 一端 Backup 才算通过；
4. 周期巡检：把「MAC 漂移记录」纳入接入层周巡检项，虚 MAC 漂移是双主类故障最灵敏的信号；
5. 有条件的场景，核心互联可将 VRRP 心跳所在 VLAN 与业务修剪解耦（如专用心跳互联），从架构上消除误剪面。

总结

这是一起「变更遗漏协议流量依赖」导致的经典 VRRP 双主故障。它的教训在于：Trunk 上的 VLAN 不只为业务数据服务，控制平面协议（VRRP 心跳、STP BPDU）同样依赖这些通道；「变更当晚 ping 正常」不代表冗余机制还健康——双主状态在低负载下几乎无感，却是一颗定时炸弹。排查此类间歇性断网，display vrrp brief 两端比对与接入层 MAC 漂移记录是两把最快的钥匙；而根治之道，是让 VRRP 状态变成「看得见、会报警」的指标，而不是等早高峰用户来当探测器。