mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
1533 字
4 分钟
控制面瞬时异常引发的 VRRP 倒换分析

在一次园区网络故障中,监控发现出口方向出现了短时连续丢包,随后由冗余协议自动恢复。

虽然业务自动恢复,但短时无征兆中断仍需要完整取证。本文围绕证据链和排查顺序展开,拓扑和日志字段统一使用通用代称。

今天就来复盘一下这次有些魔幻、且极具运维典型警示意义的故障排查过程。


1. 业务拓扑与故障现象#

先用一张简化的出口拓扑说明关系:

[用户接入区]
|
[汇聚交换机]
|
[核心交换机]
|
+-------+-------+
| |
[出口路由器-A] [出口路由器-B]
(较高优先级) (较低优先级)
| |
+-------+-------+
|
[旁路下一代防火墙组]

双出口路由器运行了专用网络操作系统,通过 VRRP(虚拟路由冗余协议) 实现双机热备。

  • 上联虚拟组连接核心交换机;
  • 下联虚拟组连接安全边界设备;
  • 正常情况下,路由器 A 作为 Master 承载流量,路由器 B 作为 Backup 待命。

监控显示异常窗口内出现连续超时,随后网络自动恢复。


2. 排查难点:遭遇数百万条垃圾日志无情“洗板”#

在故障发生后,我们第一时间登录了处于拓扑枢纽的交换机,试图查看二层链路的状态。然而,让我们大跌眼镜的事情发生了:

  • 核心交换机:本地 Logbuffer 被大量高频终端通知覆盖;
  • 汇聚交换机:接口属性告警持续刷屏,故障窗口内的关键链路记录已经无法完整还原。

运维警示:没有外置 Syslog 集中日志分析平台,且本地日志未做级别抑制,一旦遭遇垃圾日志刷板,本地的内存 Logbuffer 在极短时间内就会被稀释冲刷掉。这直接导致我们失去了从交换机视角逆向观测物理端口行为的第一现场证据。


3. 只读取证:剥茧抽丝定位根因#

既然交换机二层日志死无对证,我们只能将目标投向路由器 A 与 B 本身。通过只读取证分析,一条清晰的证据链被逐步拼接出来:

证据一:主备切换状态计数被触发#

我们查看了备用路由器 B 的 VRRP 运行统计:

Interface : <UPLINK_INTERFACE> VRID : <VRID>
Become Master : <CURRENT_COUNT>
Adver Rcvd : <CURRENT_COUNT>
Adver Sent : <CURRENT_COUNT>

统计显示,作为备机的路由器 B,其对应的 VRRP 组变为 Master 的次数曾经递增。同时它的 Logbuffer 中留存了历史倒换记录: %VRRP/STATUS_CHANGE: IPv4 virtual router changed from Backup to Master: Master-down-timer expired. 这说明主备倒换的直接原因,是备机在连续三个心跳周期内未收到主机的 VRRP 宣告报文(Adver Packet),导致 Master-down-timer 定时器超时,从而触发强行抢占。

证据二:链路并未闪断,排除二层震荡#

根据路由器 A 与 B 的端口统计,接口状态长期为 UP,丢包统计和 CRC 校验错误均为 0。汇聚交换机接口的 Last link flapping 记录也显示接口长期稳定,排除了物理链路闪断触发切换的可能。

证据三:主机时间戳不同步与固件老旧#

在比对日志时,我们发现路由器 A 与 B 的时钟存在偏差。查询显示:

  • 路由器 A 的 NTP 处于 unsynchronized 状态,导致跨设备日志的时间关联可信度降低。
  • 路由器 A 运行的专有操作系统版本非常老旧,编译于多年前,存在控制面偶发挂起等已知历史软件缺陷。

证据四:致命的业务板卡故障历史#

通过深度物理诊断,我们发现路由器 A 承载关键物理上联/下联接口的某核心加速业务板卡,其槽位在历史日志中曾有过短暂的状态故障报警反复:

%PLATFORM/BOARD_STATUS: Board status changed to Fault on Slot X.
%PLATFORM/BOARD_STATUS: Board status changed to Normal on Slot X.

虽然故障发生时该板卡已恢复正常,但历史故障告警的存在为我们指明了方向。

根因结论:#

综合现有证据,推定原因是主设备关键业务模块或控制面出现偶发性挂起。这仍是基于多项间接证据形成的分析结论,不能替代设备侧诊断。

异常窗口内,控制面可能无法正常发送 VRRP 宣告,而物理接口仍保持 UP。上游设备因此继续向主设备转发流量,备机则在宣告超时后接管。主设备恢复并重新抢占时,又产生了一次状态切换。具体时间、优先级和设备行为应以受控环境中的日志为准。


4. 改进与规避策略#

为了彻底规避这类复发风险,我们提出了以下整改方案:

  1. 启用 VRRP 抢占延迟(Preempt Delay):在主设备上配置抢占延时。防止控制平面或板卡瞬间抖动恢复后立刻触发回切,对网络 MAC/ARP 表造成二次震荡冲击。
  2. 日志分级与 Syslog 外发:部署统一的 Syslog 服务器(远端采集),并且在核心层和汇聚层交换机上过滤和抑制大量的动态 IP 分配、端口属性不匹配等超高频日常通知日志,把宝贵的日志缓冲区留给链路、STP 和 VRRP 状态。
  3. 时钟同步加固:强制为出口设备配置 NTP 客户端同步,确保整个出口区域所有设备在同一时间线上,杜绝因时钟混乱导致的日志无法关联。
  4. 系统升级与备品备件准备:安排窗口时间升级路由器老旧的系统固件;持续监控相关物理业务板卡,若再次出现 Board Fault 告警,将立即予以硬件更换。
分享

如果这篇文章对你有帮助,欢迎分享给更多人!

控制面瞬时异常引发的 VRRP 倒换分析
https://blog.luozili.work/posts/vrrp-switchover-incident-analysis/
作者
llbzow
发布于
2026-07-09
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

目录

💬
🎀