VRRP多VLAN负载分担：从原理到华为配置实战

前阵子有位朋友问我：公司三栋楼，十几个业务VLAN，网关都在两台汇聚交换机上，现在只用了 VRRP 做主备，结果是一台设备忙得不行，另一台长期空闲，问我有没有办法让两台设备都跑起来。这个问题问得很典型，因为“VRRP 实现多 VLAN 链路负载分担”这个说法本身就容易被误解。VRRP 并不能像负载均衡器那样，把同一份流量拆开分给两台设备；但如果把不同 VLAN 的虚拟 IP 分别放在两台设备上，让它们各自承担一部分业务流量，又能互相做网关备份，这确实是 VRRP 最实用的一种用法。配置本身不难，真正难的是配置之前的角色分配和故障场景规划。这篇文章我想把这条思路拆开讲清楚，不只给命令，也说清楚为什么这样做。

1. VRRP 可以被用来实现多 VLAN 负载分担，但不是靠“均分流量”

1.1 很多人理解错了 VRRP 的负载分担

VRRP 全称是 Virtual Router Redundancy Protocol，虚拟路由器冗余协议。它的设计目标很简单：一组路由器共享一个虚拟 IP，对外表现得像一台路由器；组内通过竞选产生一台 Master，Master 负责转发流量和响应 ARP，其他设备作为 Backup 监听状态，Master 宕机后立刻接替。

正因为如此，很多人想当然地认为 VRRP 能像防火墙的负载均衡一样，把连到同一个网关的流量分散到多台设备上。这是不对的。在同一个 VRRP 备份组里，同一时间只有 Master 在工作，Backup 设备对终端流量来说基本是“隐身”的。所以如果你只有一个 VLAN、一个虚拟网关，VRRP 提供的是冗余，不是负载分担。

那多 VLAN 场景为什么又能做到负载分担？关键不在于 VRRP 本身能“均分”，而在于你可以创建多个 VRRP 备份组。每个备份组有独立的虚拟 IP，也独立选举 Master。只要你在不同的 VLAN 里让不同的设备成为 Master，流量就会自然地被分到两台设备上。这种负载分担的本质是按照 VLAN 分流，而不是按连接数或报文数分发。

1.2 多 VLAN 场景下的负载分担思路：让不同 VLAN 走不同主设备

举个最简单的例子。假设有两台汇聚交换机，SW-A 和 SW-B，需要为 VLAN 10 和 VLAN 20 提供网关。

传统主备做法是：

• VLAN 10 和 VLAN 20 的 VRRP 备份组，Master 都设在 SW-A；
• SW-B 只做 Backup，任何流量都不经过它。

这种做法的问题很明显：A 设备可能需要承担 80% 的转发压力，B 设备闲置。

负载分担做法是：

• VLAN 10 的 VRRP 备份组，Master 是 SW-A，Backup 是 SW-B；
• VLAN 20 的 VRRP 备份组，Master 是 SW-B，Backup 是 SW-A。

这样，VLAN 10 的终端默认网关指向一个由 SW-A 主用的虚拟 IP，流量经 SW-A 转发；VLAN 20 的终端默认网关指向一个由 SW-B 主用的虚拟 IP，流量经 SW-B 转发。正常情况下，两台设备都在干活。如果 SW-A 宕机，VLAN 10 的虚拟 IP 会漂移到 SW-B，SW-B 同时承担 VLAN 10 和 VLAN 20 的转发，直到 SW-A 恢复。这就是“互为备份、按 VLAN 分担”的核心逻辑。

需要注意的是，这种“分担”是预先通过角色规划做到的，不是 VRRP 自动感知流量大小后动态调整的。流量到底怎么分，取决于你把哪些 VLAN 的 Master 放在哪台设备上。

1.3 这里的关键不是命令，而是 Master 和 Backup 的角色规划

我见过不少工程师，进入配置环节很快，命令敲得很熟练，但设计阶段没想清楚，结果上线后出现两种典型问题：一是某台设备仍然承担了几乎所有流量，另一台只是“象征性”用了几个 VLAN；二是在两台设备上配置的 VRRP 优先级互相冲突，切换行为不符合预期。

做角色规划时，至少要回答这几个问题：

• 哪些 VLAN 是核心业务，哪些 VLAN 是普通办公？核心业务通常建议优先放在性能更强、上行链路更可靠的那台设备上。
• 两台设备的上行链路带宽和物理路径是否一致？如果 A 的上行是 10G 核心链路，B 的上行只有 1G 专线，那么重流量 VLAN 放在 A 上会更合理。
• 一台设备故障后，另一台能否扛住全部流量？如果两台设备都是低端型号，即使 VRRP 能把流量漂移过去，也可能因为性能不足导致业务受损。
• 故障恢复时，要不要抢占？如果开启抢占，主设备恢复后会把流量抢回来；如果不开启，故障设备恢复后可能继续当 Backup，原本的流量分担规则就会被打乱。

这些问题看起来和命令无关，却决定配置最终能不能实现你想要的“负载分担”。配置 VRRP 其实很机械，真正考验的是对业务流量和设备能力的理解。

2. 配置前先把组网和 VRRP 的角色分配想清楚

2.1 典型组网：双汇聚交换机 + 多业务 VLAN

要配置多 VLAN 链路负载分担，通常有一个比较固定的组网模型：两台三层交换机作为汇聚/网关设备，下联若干台接入交换机，上联核心路由器或防火墙，两台汇聚之间建一条专用于 VRRP 报文和 VRRP 流量互通的直连链路，一般是二层 Trunk 互联。终端 PC 的网关都落在两台汇聚交换机上的 VLANIF 接口，也就是三层网关接口。

这里有一点容易混淆：VRRP 的虚拟 IP 通常就是 VLANIF 的网关地址，但它不应该和设备物理接口地址冲突。VLANIF 接口需要配置设备自身在这个网段内的 IP 地址，同时再为 VRRP 备份组配置一个虚拟 IP。两台汇聚交换机上的接口 IP 和虚拟 IP 必须在同一个网段，否则无法正常工作。

还有一个基础要求：VRRP 备份组必须在三层接口上创建，不能直接在二层接入端口上配置。华为 VRP 平台里，最常见的做法是在 VLANIF 接口下配置 VRRP。因为 VLANIF 就是终端网关所在的逻辑三层接口。

2.2 一个可落地的角色规划案例

我用一个典型案例来说明。假设业务 VLAN 有 10、20、30 三个，终端网段分别为：

• VLAN 10：192.168.10.0/24，网关为 192.168.10.1；
• VLAN 20：192.168.20.0/24，网关为 192.168.20.1；
• VLAN 30：192.168.30.0/24，网关为 192.168.30.1。

两台设备 SW-A 和 SW-B 的规划如下：

这样，正常情况下 SW-A 负责 VLAN 10 和 VLAN 30，SW-B 负责 VLAN 20。如果你希望进一步细化，还可以按照终端数量、流量模型调整。比如 VLAN 30 是视频业务，流量很大，那就考虑把它放在上行链路更好的设备上。

注意，上表中我用了不同的 VRRP 备份组编号。通常可以让 VRID 和 VLAN ID 一一对应，比如 VLAN 10 使用 vrid 10，VLAN 20 使用 vrid 20，这样维护起来直观。VRID 范围是 1-255，只要设备侧一致即可。虚拟 IP 建议不要在 DHCP 地址池内分配，否则可能出现网关地址被服务器分配出去的冲突。

2.3 优先级和抢占延时的设计决定

VRRP 通过优先级选出 Master。优先级默认是 100，范围 1-254。优先级越高，成为 Master 的可能性越大。在上面的规划里，为了让 SW-A 在 VLAN 10 里成为 Master，我把它的优先级调成 120，SW-B 保持默认或降到 90。同理，VLAN 20 里反过来。

有人会问：优先级差距是不是越大越好？不是。只要主用设备比备用设备高，选举结果就稳定。差距大一点确实更保险，可以防止因为链路抖动、设备重启时出现轻微优先级变化导致切换，但也不建议设成 254 这种极端值，否则后续如果想要通过 track 上行接口来降低优先级，剩余调整空间会很小。

另一个容易被忽略的是抢占模式。默认情况下，VRRP 抢占是开启的。也就是说，优先级高的设备恢复后，会主动夺回 Master 角色。这个行为在大多数场景是需要的，否则流量可能一直停留在另一台设备上，导致规划好的分担比例失效。但为了避免网络波动时频繁切换，主流设备都支持抢占延迟。配置时应给抢占延迟设置比如 20 秒或 30 秒，意思是 Master 恢复后先等一段时间，再抢占。如果链路只是抖了几秒钟，就不会立刻切换回来，从而降低网关闪断概率。

3. 以华为设备为例，配置 VRRP 多 VLAN 负载分担

3.1 基础配置：创建 VLAN，配置 Trunk 放通

以华为 VRP 平台的常见命令为例。不同版本可能命令有细微差异，但整体结构一致。先把 VLAN 创建出来，并把下行、上行和两台汇聚之间的互通接口配置成 Trunk，放通相关业务 VLAN。

system-view sysname SW-A vlan batch 10 20 30 interface GigabitEthernet0/0/1 port link-type trunk port trunk pvid vlan 10 port trunk allow-pass vlan 10 20 30

这里有一个容易踩坑的地方：如果接入交换机接的是普通终端，不一定需要在这个端口上配置 trunk 和 pvid。究竟使用 access 还是 trunk，取决于接入设备是否承载多个 VLAN。如果端口下接一台普通 PC，使用 access 端口划分到某个业务 VLAN 更简单；如果下接的是另一台交换机，通常使用 trunk 放通多个 VLAN。不要把业务 VLAN 作为 Trunk 端口的 PVID，除非你非常清楚自己在做什么，否则可能出现 VLAN 标签处理混乱的问题。

两台汇聚之间互联端口，建议使用 Eth-Trunk 或两条物理链路做聚合，同时放通所有需要互通的业务 VLAN。VRRP 报文通常要求在同一广播域内传输，两台汇聚交换机之间二层链路必须联通。

3.2 配置 VLANIF 和 VRRP 备份组

在 SW-A 上配置 VLANIF 10、VLANIF 20、VLANIF 30，并在每个 VLANIF 下创建对应 VRRP 备份组：

interface Vlanif10 ip address 192.168.10.2 255.255.255.0 vrrp vrid 10 virtual-ip 192.168.10.1 vrrp vrid 10 priority 120 vrrp vrid 10 preempt-mode timer delay 20 interface Vlanif20 ip address 192.168.20.2 255.255.255.0 vrrp vrid 20 virtual-ip 192.168.20.1 vrrp vrid 20 priority 90 vrrp vrid 20 preempt-mode timer delay 20 interface Vlanif30 ip address 192.168.30.2 255.255.255.0 vrrp vrid 30 virtual-ip 192.168.30.1 vrrp vrid 30 priority 120 vrrp vrid 30 preempt-mode timer delay 20

在 SW-B 上配置类似，但要把优先级反过来，注意每个接口下的设备 IP 和虚拟 IP 的网段要一致，比如 SW-B 的 VLANIF20 配置为 192.168.20.3，虚拟 IP 仍是 192.168.20.1。

interface Vlanif10 ip address 192.168.10.3 255.255.255.0 vrrp vrid 10 virtual-ip 192.168.10.1 vrrp vrid 10 priority 90 vrrp vrid 10 preempt-mode timer delay 20 interface Vlanif20 ip address 192.168.20.3 255.255.255.0 vrrp vrid 20 virtual-ip 192.168.20.1 vrrp vrid 20 priority 120 vrrp vrid 20 preempt-mode timer delay 20 interface Vlanif30 ip address 192.168.30.3 255.255.255.0 vrrp vrid 30 virtual-ip 192.168.30.1 vrrp vrid 30 priority 90 vrrp vrid 30 preempt-mode timer delay 20

这里要解释一个细节：设备本身的三层地址（比如 192.168.10.2）和虚拟网关地址（192.168.10.1）必须同网段，通常这两个地址都不会和终端动态获取的地址冲突。如果业务网段使用 DHCP 分配地址，最好在 DHCP 地址池里排除虚拟网关地址。

配置完成后，两台设备会在同一个 VRRP 备份组中互相交互 VRRP 报文，报文用组播地址 224.0.0.18 发送，协议号是 112。正常情况下，SW-A 会在 VLAN 10 和 VLAN 30 的备份组中成为 Master，SW-B 会在 VLAN 20 的备份组中成为 Master。

3.3 通过 Track 感知上行链路故障

仅仅配置优先级和抢占还不够。VRRP 默认感知的是三层接口状态和备份组内部报文，它无法直接感知“这台设备的上行链路是否断了”。如果 SW-A 的上行接口 Down 掉，但 VLANIF 接口和 VRRP 状态仍然正常，VLAN 10 和 VLAN 30 的 Master 还会是 SW-A，结果就是终端网关仍然可用，但流量出不去，形成典型的黑洞。

解决思路是使用 track 功能监控上行接口或下一跳。当被监控对象失效时，本设备的 VRRP 优先级自动降低，让对方成为 Master。华为设备常见的写法是在 VRRP 备份组下关联一个 Track 项：

interface Vlanif10 vrrp vrid 10 track interface GigabitEthernet0/0/2 reduced 40

意思是，如果 SW-A 的上行接口 GigabitEthernet0/0/2 Down，则 VLAN 10 的 VRRP 优先级减少 40。原本是 120，降为 80，低于 SW-B 的 90，SW-B 就会在抢占延迟后成为 Master。这个机制非常关键，我后面还会专门说。

3.4 验证配置：看状态、看统计、看接口

配置完成后，不能直接切业务，先验证一下。常用命令有：

display vrrp brief display vrrp display vlan display interface Vlanif10 display int vlan brief

display vrrp brief会输出每个 VRRP 备份组的状态。这里要重点关注的是 State 字段，Master 和 Backup 是否符合你最初的规划。如果在 LAN 10 中 SW-A 显示 Backup、SW-B 显示 Master，就说明优先级或抢占配置有问题。

display interface Vlanif10可以用来查看 VLANIF 接口的 IP 地址和物理状态。如果接口状态一直是 Down，VRRP 是无法正常工作的。

接入交换机也可以用display int vlan brief查看接口所属 VLAN 和 VLAN 是否激活，这是排查“终端能起来但网关不通”时的常用手段。

4. 配置完先别急着切业务，按这个链路排查

4.1 先看现象分类，再决定从哪层查

VRRP 多 VLAN 负载分担配置完成后，最容易出现的现象无非这么几类：

• 终端无法 ping 通虚拟网关地址；
• 终端能 ping 通 A 设备的物理接口 IP，但 ping 不通虚拟 IP；
• 终端能 ping 通网关，但跨 VLAN 通信或上互联网失败；
• 主备切换后业务长时间中断；
• VRRP 状态来回切换，日志里不断出现 Master 变化。

这些现象对应的排查层次不一样。我一般会按照“物理接口和 VLAN -> VRRP 状态 -> 上行链路和路由”的顺序来排查，不要一开始就去改参数。

4.2 第一层：物理接口和 VLAN

先看接入交换机到汇聚交换机的链路。用display interface brief查看端口是否 Up，再用display vlan或display int vlan brief确认业务 VLAN 是否已经在相关端口放通。

如果终端到汇聚之间的中间链路有 Trunk，必须保证所有路径上的 Trunk 都放通了业务 VLAN。有一个非常常见的坑：接入交换机接终端的口是 access VLAN 10，但接入交换机上联汇聚的口忘记在 trunk 中放通 VLAN 10，结果终端本身能拿到 VLAN 10 的地址，却因为汇聚交换机收不到 VLAN 10 的报文导致网关不可达。

还要检查 Trunk 的 PVID。默认 PVID 是 VLAN 1，如果业务 VLAN 是 10，并且 Trunk 口没有调整 PVID 或对端不匹配，有时会导致 VLAN 标签处理异常。尤其是在 Cisco 和华为设备互联时，PVID 的行为可能会有差别。

4.3 第二层：VRRP 状态和报文

如果 VLAN 和接口都正常，再看 VRRP。使用display vrrp brief查看各备份组状态。如果状态一直停留在 Master 或 Backup 不切换，先确认两台设备是否能看到对方的 VRRP 报文。

VRRP 依赖组播报文，组播地址是 224.0.0.18，协议号是 112。在这个传输路径上，任何交换机或防火墙都不能过滤掉这些报文。有的三层设备默认开启了组播抑制，会导致 VRRP 无法协商，表现为两台设备都认为自己是 Master。这在大网络上尤其常见。

排查时可以在一台设备上使用 debug 查看 VRRP 报文收发，但生产环境不建议长时间开启。更稳妥的方法是检查两台设备间二层链路是否允许组播，以及是否有 ACL 在防火墙或交换机上拦掉了协议 112。

4.4 第三层：上行链路和路由

VRRP 配置正确，不代表数据能出去。如果终端能 ping 通虚拟网关，但跨 VLAN 或上互联网不通，问题往往在上层路由。

在负载分担的设计里，VLAN 10 的 Master 是 SW-A，VLAN 20 的 Master 是 SW-B。如果上层路由器只配置了回程路由指向 SW-A，那么当 VLAN 20 的流量从 SW-B 转发到上层后，回程包可能被路由器发给 SW-A，而 SW-A 上没有 VLAN 20 的准确 ARP，就会造成往返路径不一致，表现为“能发出去，但收不到回包”。

解决这类问题，通常需要在上层设备上配置等价路由，把两个方向都指向两台汇聚设备，或者使用策略路由确保回程流量从哪台设备进来就从哪台设备回去。否则，即使 VRRP 状态完全正确，业务仍然会半通或不通。

4.5 几个容易反复折腾的坑位

• 虚拟 IP 和 DHCP 地址池冲突，导致终端地址被占用。
• 两台设备的 VRRP 版本不一致，导致协商失败。
• 抢占延时设置太短，链路抖动时 Master 频繁迁移。
• 开启了漂移 IP 上送防火墙，但防火墙没有放通 VRRP 协议号 112，导致备机收不到报文。
• 配置了 VRRP 备份组数量很多，但没有整理规划表，现场运维时根本分不清哪个 VLAN 应该由哪台设备主用。

这些坑都不难解决，但容易反复。建议把角色规划表打印出来或写入变更记录，方便定期巡检时对照。

5. 从“配置成功”到“长期稳定运行”，还差几步

5.1 切换测试不能只在模拟器里做

很多人用 ENSP 或 EVE-NG 搭好环境，测试 VRRP 切换很顺畅，就觉得生产环境也能直接上。模拟器验证的是配置逻辑，但不能完全模拟真实设备在业务压力下的表现。

生产环境上线前，我建议至少做四类切换测试：

1. 主设备整机重启，观察另一个设备是否能在预期时间内接管网关。
2. 主设备上行接口 Down，观察 Track 机制是否触发优先级降低，备机是否接管。
3. 备设备直接断电，观察主设备是否受到任何影响。
4. 主设备恢复后，观察抢占延时是否起作用，是否出现业务闪断。

测试不仅要看 VRRP 状态变化，还要记录终端 ping 网关的丢包数。一次正常切换，丢包数量应当很有限；如果丢包达到几十秒，说明可能是 ARP 学习、STP 收敛或端口状态恢复太慢导致，需要进一步优化。

5.2 注意 Track 不只是“锦上添花”

我在前面重点提过 Track。这里再强调一次：如果 VRRP 不感知上行链路故障，那么双机冗余只解决了“设备坏了”这种故障，没有解决“链路断了”这种更常见的故障。

生产环境中，上行链路 Down 比整台设备挂掉发生得更频繁。只有配置了 track 接口或 track 下一跳，才能让 VRRP 在主设备上行不可达时主动降权，让备机接管所有业务。这个能力对多 VLAN 负载分担尤其重要，因为不同 VLAN 的主用设备分布在不同硬件上，如果某台主用设备的上行断了，对应 VLAN 必须快速切换到另一台设备。

如果设备不支持 track 接口，也可以用 NQA 或 BFD 检测上行下一跳，再联动 VRRP 优先级。功能上更加可靠，但配置复杂度也会上升。无论哪种方式，都要保证“检测链路故障”的能力比终端用户感知更快。

5.3 上线后的巡检和维护清单

VRRP 配置本身不复杂，但维护需要纪律。我整理了一份适合周期性巡检的清单：

• 定期执行display vrrp brief，核对每台设备的 Master 角色是否和规划一致。
• 检查所有 VLANIF 的接口状态和地址是否发生变化。
• 检查 Trunk 放通列表，防止新加 VLAN 后忘记放通。
• 查看设备日志，确认是否存在 VRRP 频繁切换或反复 Down 的记录。
• 开启 SNMP 监控，把 VRRP 状态变化上报给网管，不要等业务投诉才发现切换。
• 配置统一 NTP，确保两台设备时间一致，否则日志排查时间线会很混乱。
• 保存配置文件，定期备份，变更前保留回退点。

这套清单本身不复杂，但很多网络事故都源于“配置完就忘了它还在那里跑”。

5.4 什么时候该用 VRRP，什么时候它不够用

VRRP 多 VLAN 负载分担适合的核心场景是：两台三层交换机做同网段的网关冗余，业务 VLAN 数量在两三个以上，设备性能可以支撑单台故障后承接全部流量，且对切换时间要求不是极端苛刻。

但它也有限制。比如：

• 单台设备故障后，另一台要承担全部流量。如果每台设备的性能都只够承载 60% 的流量，故障后就会过载。这时靠 VRRP 分担无法解决，只能升级设备或用集群方案。
• VRRP 工作在同一个二层域。如果两台设备跨数据中心部署，中间跨越二层大网，VRRP 可能会受到网络延时和故障域扩大的影响，不如动态路由协议更适合。
• VRRP 无法实现真正的流量负载均衡，只能按 VLAN 分配。如果需要把同一 VLAN 内部的大量连接分散到多台设备上，VRRP 做不到。

所以在规划的时候，最好把 VRRP 看成“网关高可用方案”，而不是“流量调度方案”。它能让两台设备都用起来，也能在故障时互相兜底，但你还是要单独评估单台设备故障后的承载能力。

回到最开始那位朋友的问题。我的建议很明确：先用一张表把每台设备负责哪些 VLAN 写清楚，确认两台设备的上行链路和性能边界，再把 VRRP 优先级、抢占延时和 Track 机制配置好，最后做一次完整的切换演练。命令只是最后一步。网络工程里，配置 VRRP 的人很多，能把故障场景提前想透的人不多。多 VLAN 负载分担带来的不只是设备利用率提升，更是一种“让两台设备都处在真实工作状态”的维护思路——毕竟，长期闲置的备用设备，往往比一直在跑的设备更容易在关键时刻出问题。