企业官网建设流程全解析

1. 为什么突然聊VRRP：一个真实故障引出的选题

先说个我前段时间遇到的现场问题。某个客户的网络架构其实很常规，核心交换机做了堆叠，下联各楼栋的接入交换机，网关全部放在核心上。听起来没啥毛病，但某天运维群里炸了：办公网大面积断网，ping网关直接超时，重启完汇聚设备又恢复，过一阵又断。查了几天，最后的根因说出来你可能不信——有人在交换机的某个VLAN接口上手动配了一个同网段的VRRP备份组，虚拟IP和核心网关一模一样，而且优先级比核心还高。于是核心那边一直在抢占、让位、再抢占，整个网段的流量像坐过山车一样反复横跳。

这个案例让我意识到，VRRP这东西，很多人只知道“虚拟网关冗余”这六个字，但真正抓包看协议交互、看状态机切换、看报文超时，遇到问题还是两眼一抹黑。正好手头有一台测试设备可以组一个最小拓扑，这次就用Wireshark把VRRP从原理到排障完整过一遍。

这篇文章适合谁看？三类人：一是网络运维工程师，天天跟网关、冗余打交道但没细看过协议报文；二是准备网络认证考试（华为、思科都可以，VRRP和HSRP原理相通）的考生，抓包能帮你把状态机彻底吃透；三是搞网络安全、做流量分析的朋友，多熟悉一种协议报文的特征，以后在抓包文件里一眼认出VRRP，排查环路或者网关冲突会快很多。

2. 折腾前必看：VRRP的工作机制和报文结构

2.1 虚拟网关的“户口本”：VRRP MAC地址到底长啥样

VRRP全称Virtual Router Redundancy Protocol，虚拟路由冗余协议。它的核心思路是：把多台路由器（或者三层交换机）组成一个备份组，对外共享一个虚拟IP作为网关。实际转发流量的那台叫Master，其他设备叫Backup。Master挂了，Backup里面优先级最高的顶上，整个切换过程对终端完全透明——终端根本不需要改网关，因为它的ARP缓存里，网关IP对应的MAC地址始终是那个虚拟MAC。

那虚拟MAC是多少？标准里写得很清楚：00-00-5E-00-01-XX。前三段是IANA分配给VRRP的OUI，XX是VRRP的VRID（虚拟路由器ID）。比如VRID是1，虚拟MAC就是00-00-5E-00-01-01。这个细节太重要了，后面抓包排查的时候，看到目标MAC或者源MAC是00-00-5E-00-01-xx开头的，基本就能锁定是VRRP的流量。

这里顺便说一句，思科的私有协议HSRP（Hot Standby Router Protocol）虚拟MAC是00-00-0C-07-AC-XX，华为的VRRP跟标准RFC 3768、RFC 5798是一致的。如果你在抓包里看到00-00-0C-07-AC开头，那是HSRP不是VRRP，别搞混了。排查跨厂商设备的时候，这个细节能帮你省不少时间。

2.2 谁是老大、怎么选出来的：优先级和抢占机制

VRRP设备之间靠什么决定谁当Master？就两个东西：优先级和IP地址。

优先级数值范围是1到254，默认100。选举规则是数值大的当Master，如果优先级一样，就看接口的主IP地址，大的当Master。这个跟OSPF的DR选举有点像，但VRRP更简单粗暴：它不搞什么“不抢占”的花活（抢占默认也是开着的）。

实际部署的时候，一般会把核心交换机A的优先级设成120，核心交换机B保持默认100。正常情况下A是Master，B是Backup。A的链路或者整机挂了，B收到超过Master_Down_Interval（这个时间下面细说）时间没有Master的广告报文，就会立刻升为Master，接管虚拟IP和虚拟MAC，继续转发流量。等A恢复之后，因为它的优先级更高，会重新抢占回Master的位置。

抢占机制在绝大多数场景下是好事，但有一种情况特别坑：主备设备之间链路质量不稳定，一会儿通一会儿断。备设备刚升成Master，主的又恢复了马上抢回去，网络来回抖。这种场景建议把主设备的抢占关掉（华为的命令是vrrp vrid 1 preempt-mode disable），让它在恢复后老老实实当Backup，避免流量被来回踢皮球。

2.3 报文里到底写了什么：VRRP报文字段逐个拆

VRRP报文是基于IP协议直接封装的，协议号是112，IP头里的TTL字段固定为255，目的地址通常是组播地址224.0.0.18（VRRP专用组播）。我把常见字段整理成一张表，抓包的时候对照着看会很清晰：

这里要注意，VRRPv2和VRRPv3除了版本号不同，v3是支持IPv6和IPv4双栈的，而且通告间隔的单位从秒变成了厘秒（所以默认值是100而不是1）。新部署或者排障的时候，先确认设备跑的是v2还是v3，不然看到通告间隔的数值会发懵。

另外，认证字段值得一提。VRRPv2的简单文本认证（Auth Type=1）其实就是个摆设，报文明文抓包就能看到密码，根本起不到安全作用。VRRPv3干脆把这个字段砍了，取而代之的是IPsec认证（实际用得也少）。所以做网络安全审计的同学，如果看到线上网络还在用VRRPv2的文本认证，该提醒下这是个隐患。

3. 复现环境搭建：两台设备一个虚拟网关的最小拓扑

3.1 手头没有真机怎么办：用GNS3快速搭一套

排障和验证串口抓包最理想的是拿真机来测，但多数人家里不会有交换机。我的建议是用GNS3加两台思科IOS镜像，或者华为的eNSP（如果你有思科和华为的镜像都行），跑一个最简拓扑：

• 设备A：GNS3里的路由器，起一个三层接口，配好物理IP，再配置VRRP，优先级设120。
• 设备B：另一台路由器，同样接口，优先级保持默认100。
• 下面挂一台PC或者一台二层交换机，PC的网关指向虚拟IP。
• PC和路由器的互联链路中间接一个集线器或者配了镜像口的交换机，方便Wireshark抓包。

拓扑看起来像这样：PC — 二层交换机 —（镜像口接Wireshark）— 路由器A / 路由器B。抓包点放在PC和网络设备之间的链路上，能看到终端发出的ARP请求、VRRP组播报文以及各设备之间的转发流量。

如果你手头有真实的华为交换机，配置更简单。两个交换机做VRRP的典型配置模板下面会完整给出来，这里先用GNS3把原理跑通，一样的。

3.2 华为交换机的VRRP配置模板（可直接抄）

假设场景是：核心交换机A和B都接在同一个二层域里，网段是192.168.10.0/24，虚拟IP是192.168.10.254，A的物理接口IP是192.168.10.251，B是192.168.10.252。

设备A的配置：

interface Vlanif10 ip address 192.168.10.251 255.255.255.0 vrrp vrid 1 virtual-ip 192.168.10.254 vrrp vrid 1 priority 120 vrrp vrid 1 preempt-mode timer delay 10 vrrp vrid 1 track interface GigabitEthernet0/0/1 reduced 30

设备B的配置：

interface Vlanif10 ip address 192.168.10.252 255.255.255.0 vrrp vrid 1 virtual-ip 192.168.10.254

这段配置里有几个细节要展开讲：

第一，preempt-mode timer delay 10这条。它的意思是设备A恢复后延迟10秒再抢占。这10秒是为了等设备A的上联链路、路由表完全收敛，避免刚恢复就抢回Master，结果路由还没学全，导致流量黑洞。实际生产中这个延迟建议配5到15秒，视复杂度而定。

第二，track interface这条。它监控的是设备A的上联口GigabitEthernet0/0/1，如果这个口down了，优先级自动降30。这时候A的优先级就从120降到90，低于B的100，B就会接管网关。这个机制解决了VRRP一个著名痛点：设备本身没坏，但上联链路断了。如果不做接口跟踪，A还是Master，但流量到了A却出不去，整个网段就废了。这个坑很多初学VRRP的人没注意到，实际上生产环境里这是必配项。

第三，优先级降到90，不是降到0。这里有个临界点问题。如果你不配track interface，优先级是120；配了之后链路故障时降30变成90。但如果你原本优先级就配了110，降30就变成80，B的优先级100照样能抢过来。但要注意，如果B那边的优先级也是120，两边相等就靠IP地址比大小，谁IP大谁是Master，这种优先级配置打架的情况，故障时选主会变得不可控。所以规划优先级的时候，主备用之间建议拉开30以上的差距，别卡在临界值。

3.3 开始抓包前的Wireshark准备工作

在GNS3里拓扑启动后，别急着点抓包。先把过滤条件写好。VRRP在Wireshark里已经内置了解析器，直接用vrrp作为显示过滤器就行。但有个坑：如果你抓包的时候VRRPv3的报文被识别成ip.proto==112而不是vrrp，说明Wireshark版本比较老或者没装好解析插件。这时候可以用ip.proto==112兜底过滤，效果一样。

另外，建议在抓包开始前把Wireshark的“着色规则”看一眼，默认情况下VRRP流量是不着色的，混在一堆组播报文里不太明显。Wireshark 4.0以上版本可以在“视图 -> 着色规则”里手动加一条：过滤器vrrp，前景色白色、背景色深紫，这样一眼就能在时间轴上看到VRRP报文的节奏。

4. 核心实战：Wireshark抓包看VRRP的全过程

4.1 主备都正常时，每秒一发的通告报文长什么样

拓扑启动，PC的网关是192.168.10.254，设备A是Master，设备B是Backup。这时候链路上会周期性出现VRRP Advertisement报文，抓包后第一眼看到的就是这幅画面。

用vrrp过滤后，你会看到源MAC是A的物理接口MAC还是虚拟MAC？这里有个很多人搞错的地方。VRRP Advertisement报文封装在以太网帧里的时候，源MAC用的是发送接口的物理MAC，不是虚拟MAC；目的MAC用的是虚拟MAC00-00-5E-00-01-01，不是组播MAC。换句话说，VRRP的组播是IPv4层面的组播（224.0.0.18），但二层帧的目的MAC是VRRP虚拟MAC，这跟普通IP组播报文的组播MAC映射规则不一样。Wireshark的Expert Info里如果出现“Invalid VRRP MAC”之类的警告，多半就是有人手工改过虚拟MAC或者设备实现有坑，这点在跨厂商对接时尤其值得留意。

点开一个VRRP报文，你会看到典型的字段：

Virtual Router Redundancy Protocol Version: 2 Type: Advertisement (1) Virtual Rtr ID: 1 Priority: 120 Count IP Addrs: 1 Auth Type: No Authentication (0) Adver Int: 1 Checksum: 0x9f51 [correct] IP Address: 192.168.10.254

这个报文不长，总共也就20多个字节的负载。但它每一秒发一次，用的是组播地址，局域网里所有运行了VRRP的设备都能收到。Backup B收到后会刷新一个定时器，确认A还活着，自己继续安心当备胎。如果B连续Master_Down_Interval（计算方法是3 × Adver_Int + Skew_Time）时间没收到报文，就开始进入竞选流程。

这里的Skew_Time等于（256 - Priority）/256秒。为什么要有它？主要是防止多台Backup同时升Master造成报文冲突。优先级越高的Backup，Skew_Time越小，能在更接近3 × Adver_Int的时刻触发切换，这样即便多台备用设备，也会有一个清晰的时间梯度，避免大家在同一微秒抢着发广播。

4.2 手工杀掉Master，看Backup如何秒变网关

现在在GNS3里把设备A的接口直接shutdown，模拟Master宕机的场景。Wireshark上会看到什么？

首先，原本身为Backup的设备B会等待Master_Down_Interval时间（默认3秒多一点，因为Adver_Int是1秒、B的优先级100算下来Skew_Time是(256-100)/256=0.609375秒，所以总等待大约是3.6秒），然后立刻开始发送VRRP Advertisement报文，优先级是它自己的100，报文源MAC变成自己的物理接口MAC。

关键点来了：B升为Master之前，会先发送一个免费ARP（Gratuitous ARP）报文，广播宣告192.168.10.254对应的MAC地址是虚拟MAC00-00-5E-00-01-01。这是整个切换流程里对终端影响最大的一步——它让局域网里所有终端的ARP缓存立刻刷新，网关MAC从A的物理MAC切换成虚拟MAC（其实正常情况下终端ARP缓存里的网关MAC本来就是虚拟MAC，但如果之前发生过Master抢占，缓存里的网关MAC可能短暂指向A的物理MAC；B升空后发免费ARP，就是强制大家把网关MAC刷成虚拟MAC）。

抓包的时候关注这个免费ARP的来源IP是192.168.10.254而不是192.168.10.252，这一点在排障的时候特别重要。如果你看到终端持续向旧的物理MAC发数据，但网上查不到对应的免费ARP，那就说明Master切换后免费ARP丢了或者被设备拦截了。这类问题在开启端口安全或者启用动态ARP检测的交换机上特别常见，后面我单独讲。

B升为Master后，会立刻把接口IP地址和MAC地址做一次绑定，同时向组播地址发一个自己的VRRP Advertisement。这个时候抓包会看到VRRP报文的优先级从100变成了当前B自己的优先级，说明Master状态已经转移。对PC来说，整个过程几乎无感，最多就是丢一两秒的包——这取决于PC的ARP缓存对虚拟MAC是否保持稳定。

4.3 抓包看抢占：高优先级设备恢复后的移交流程

这是我最喜欢演示的场景，因为很多人在生产环境里不敢乱动设备，但在GNS3里随便玩。把A的接口重新no shutdown，看Wireshark里发生了什么。

A恢复后，接口UP起来，它作为默认抢占者，会等待约preempt-mode timer delay配置的延迟（生产环境常见配置为10秒），然后向组播地址发一个VRRP Advertisement，里面优先级是120。B收到后一比对：优先级120 > 自己的100，于是B立刻降级为Backup，同时A升为Master。

这里要留意一个细节：抢占触发的瞬间，新的Master（A）也会发免费ARP。它的作用和上面B升Master一样，都是为了让终端刷新ARP缓存，确保流量切到新Master。如果你在Wireshark里看到VRRP Advertisement报文之后紧接着出现一条免费ARP，基本就可以确认抢占切换的过程是完整健康的。

但有一种情况会导致切换出问题：A恢复后，接口UP了，但它的上行路由还没有完全收敛。如果抢占延迟设置得太短（比如没配preempt-mode timer delay，直接恢复就抢），就会出现“Master活着但业务不通”的现象。这也是为什么我一直强调抢占延迟一定要配，不要觉得它多此一举。

5. 进阶场景：VRRP报文里藏着哪些排障信号

5.1 抓包文件里没有VRRP报文：可能压根没跑起来

如果你的Wireshark什么都抓不到，没有任何VRRP Advertisement，先别急，分几步排查：

第一，确认路由器的接口是否UP。VRRP只会在接口状态UP的情况下才会发送Advertisement。接口down了，VRRP直接哑火。

第二，确认VRID配置是否正确。两台设备配置的VRID必须一致，一个配了VRID 1，另一个配了VRID 2，它们根本不在同一个备份组里，谁都不会理谁，自然也就没有报文交互。

第三，确认组播是否被过滤。VRRP用的组播地址是224.0.0.18，如果中间的二层设备开了一些IGMP snooping功能并且处理不当，可能会把这个组播流量当成普通组播给过滤掉。虽然224.0.0.18属于链路本地组播，正常情况下不会被IGMP snooping裁剪，但在某些特殊交换机配置里确实会出现异常。建议先确认自己和设备中间的二层链路没有奇怪的ACL或者组播过滤规则。

5.2 虚拟IP配置不一致：两边Gateway各说各话

这里存在一个经典错误：两台设备的VRRID都是1，但虚拟IP一个配的是192.168.10.254，另一个配的是192.168.10.253。两台都在发VRRP Advertisement，但报文里携带的IP地址不一样。Wireshark里能看到两个VRID相同的VRRP报文，优先级不同，但虚拟IP字段不同。

这种情况下，局域网终端会间歇性收到不通的免费ARP，有的终端ARP缓存指向..254，有的指向..253，于是整个网段的“网关”都不一样，表现出来就是部分终端能上网、部分终端突然断网，重启网卡或清ARP又恢复，过一阵又有人断网。这类问题最烦人，因为症状像ARP欺骗。但只要你抓包看VRRP报文里的IP Address字段，马上就能定位是配置冲突。

5.3 优先级反复横跳：两台设备都觉得自己是Master

另一个经典异常：两台设备的VRRP接口都频繁发Advertisement，优先级都是100，导致频繁抢占。抓包看起来就是两个IP不同的VRRP报文交替出现，每隔几秒源MAC变一次。这种情况的典型原因有：

• 两台设备的优先级配置反了，A想当Backup，B想当Master，结果全网没有一个稳定的Master。
• 两台设备之间的链路不稳定，导致Backup收不到Master的通告，超时后又升Master，恢复后又退让，周而复始。

用Wireshark看这个现象最简单的方法：看VRRP报文里Priority字段的数值变化，以及报文的源MAC地址是否频繁切换。稳定状态下，应该只有Master周期性地发Advertisement，Backup基本不发（某些实现里Backup可能会在收到高优先级报文后发一次确认，但多数情况下安静）。如果你看到两个源交替发报文，且优先级数值忽高忽低，基本可以锁定是抢占抖动问题，先去查主备之间的链路质量。

5.4 认证不匹配：静默的Backup

VRRPv2环境下，如果一台配置了简单文本认证，另一台没配，它们之间也能互相收到报文，但会做认证校验。不通过的话，Backup会直接把报文丢弃，不更新定时器。表现就是：一台设备在发Advertisement，另一台完全没反应，既不切换也不报错，非常隐蔽。

Wireshark里看配置了认证的报文，Auth Type字段会显示1，并且下面会带一个文本字符串。抓包时如果你发现设备之间报文正常，但有一台始终是Init状态（华为的display vrrp能看到），就要怀疑是不是认证类型或者密码不一致。同理，如果设备之间跑VRRPv3，认证字段根本不存在，就不用纠结密码了，直接看版本是否一致。

6. 生产环境排障高频问题速查表

把这段时间做VRRP抓包分析遇到的典型问题和对应排查方法整理成一个速查表，方便放到你的运维笔记里：

这个表格看着简单，但每一条我在现场都撞过。这里面最值得警惕的是“免费ARP被拦截”这条。现在的园区网普遍做了端口安全和动态ARP检测，如果接入交换机把网关的免费ARP当成非法ARP处理了，VRRP切换再快、报文发得再标准，终端缓存就是刷不过来，用户该断网还是断网。排查的时候别光盯VRRP报文，免费ARP能不能正常广播到终端，一样重要。

7. 写在最后：抓包这件事，纸上谈兵不如实际敲一遍

VRRP这个协议，光看文档你会觉得它简单——就是一个主备切换、一个虚拟IP、一个优先级。但真正排障的时候，涉及的坑一个接一个。我个人经验是，凡是遇到“网关间歇性不通”“主备切换之后业务还是断”“网上查不到问题”的案例，先抓包看三样东西：VRRP Advertisement是否稳定、免费ARP是不是及时发出、终端ARP缓存有没有更新。这三样对上了，大部分问题都能直接定位。

最后再分享一个小技巧：用Wireshark看VRRP的时候，把时间列调整成“Seconds Since Previous Captured Packet”（右键时间列，选择“列首选项”），然后观察相邻两条VRRP报文的间隔。正常情况下稳定在一秒（或者你配置的通告间隔）。如果你发现间隔忽长忽短，或者经常超过三秒才收到一条，那这个网络的上行链路或者设备CPU八成在打嗝，提前排查比等Master Down再救火要省心得多。