VRRP负载均衡模式配置实用吗？

在前面的文章中，我们知道了VRRP单备份组可以快速实现主备切换（），轻轻松松将业务中断时间压缩到1秒钟以内；也对比测试了策略路由进行主备切换的过程（），虽然能轻松实现主备设备之间的流量负载，但是受实现机制影响，策略路由无法及时感知下一跳的路径变化，可能会导致10秒钟以上的通信中断，对业务影响可能会比较大。

紧接着，我们又测试了VRRP多备份组和策略路由的组合方案（），通过VRRP多备份组来实现设备间的主备，通过策略路由来实现流量在不同VRRP备份组之间的负载分担。

其实，在VRRP标准协议模式中，只有Master路由器可以转发报文，Backup路由器处于监听状态，无法转发报文。但是VRRP还支持负载均衡模式，在VRRP提供的虚拟网关冗余备份功能基础上，将一个虚拟IP地址与多个虚拟MAC地址对应（每台路由器都对应一个虚拟MAC地址），类似于负载均衡的三角传输模式（以后会介绍到），使用不同的虚拟MAC地址应答主机的ARP请求，从而使得不同主机的流量发送到不同的路由器，备份组中的每台路由器都能转发流量。

发现了没，好像在传统场景中并不是很实用，因为一般VRRP配置在核心交换机和出口路由器设备之间，一台核心交换机不能同时记录2条不同的ARP表项，会导致配置无法生效。

那我们要怎么测试负载效果呢？把交换机作为二层使用，网关直接配置成VRRP的虚拟IP地址，注意看我操作。

组网需求

1、核心交换机CORESW配置工作在二层模式；

2、配置VRRP1和VRRP2工作在VRRP备份组10中，手工配置VRRP1为主设备，VRRP2为备设备。当VRRP1正常工作时，PCA发送到ISP的报文经VRRP1转发；当VRRP1出现故障时，PCA发送给业务地址8.8.8.8的报文通过VRRP2转发；

3、DHCP服务器为主机PCA、PCB、PCC动态分配IP地址信息，网关为VRRP备份组的虚拟IP地址10.1.1.1/24；

4、备份组10工作在负载均衡模式，通过配置负载分担，充分利用网关资源；

5、在VRRP1和VRRP2上分别配置Track项监视上行接口的状态，当上行接口出现故障时，降低VRRP1或VRRP2在VRRP备份组中的权重，以便其它设备及时抢占为Master，接管转发任务。

组网图

VRRP负载均衡模式配置组网图：

 

实验环境

Windows 10专业版（1909-18363.1556，16 GB内存）

HCL 3.0.1

MSR 36-20（Version 7.1.064, Release 0821P11）

S5820V2-54QS-GE（Version 7.1.075, Alpha 7571）

配置步骤

我们先完成VRRP1和VRRP2上有关VRRP备份组的配置。

VRRP1

首先配置VRRP工作在负载均衡模式。

#

 vrrp mode load-balance

配置接口GigabitEthernet0/0 的真实IP地址，创建备份组10，并配置备份组10的虚拟IP地址为10.1.1.1，为保证VRRP1顺利选举为Master设备，我们将其优先级配置为200。为了避免VRRP1故障恢复后立即抢占成为Master，我们将抢占延迟时间配置为2000厘秒（20秒）

#

interface GigabitEthernet0/0

ip address 10.1.1.11 255.255.255.0

 vrrp vrid 10 virtual-ip 10.1.1.1

 vrrp vrid 10 priority 200

 vrrp vrid 10 preempt-mode delay 2000

创建和上行接口GigabitEthernet0/1物理状态关联的Track项1，当上行接口出现故障时，Track项的状态切换为Negative。

#

track 1 interface GigabitEthernet0/1

当Track项的状态切换为Negative时，配置联动项降低VRRP1的优先级，使其低于失效下限10，以便VRRP2及时抢占为Master，接管转发任务。

#

interface GigabitEthernet0/0

vrrp vrid 10 track 1 priority reduced 250

设备的其他配置如下：

#

interface GigabitEthernet0/1

ip address 20.1.1.1 255.255.255.0

 nat outbound

#

 ip route-static 0.0.0.0 0 20.1.1.2

VRRP2

参考VRRP1，完成VRRP2的设备配置，具体配置如下：

#

track 1 interface GigabitEthernet0/1

#

interface GigabitEthernet0/0

ip address 10.1.1.22 255.255.255.0

 vrrp vrid 10 virtual-ip 10.1.1.1

 vrrp vrid 10 track 1 priority reduced 250

#

interface GigabitEthernet0/1

ip address 30.1.1.1 255.255.255.0

 nat outbound

#

 ip route-static 0.0.0.0 0 30.1.1.2

DHCP

配置DHCP服务器为主机PCA、PCB、PCC动态分配IP地址信息，分配VRRP备份组的虚拟IP地址10.1.1.1/24为网关；

#

 dhcp enable

#

dhcp server ip-pool vrrp

 gateway-list 10.1.1.1

 network 10.1.1.0 mask 255.255.255.0

 dns-list 8.8.8.8

#

interface GigabitEthernet0/0

ip address 10.1.1.254 255.255.255.0

ISP

#

interface LoopBack1

 ip address 8.8.8.8 255.255.255.0

#

interface GigabitEthernet0/0

ip address 20.1.1.2 255.255.255.0

#

interface GigabitEthernet0/1

ip address 30.1.1.2 255.255.255.0

验证配置

我们在PCA上开启DHCP自动获取IP地址。

#

interface GigabitEthernet0/0

ip address dhcp-alloc

查看IP地址获取情况。

 

查看ARP信息，可以看到网关的MAC地址显示为000f-e2ff-00a1。

 

然后我们看一下VRRP1设备上备份组的详细状态信息。

 

可以看到，VRRP的工作模式为Load balance负载均衡模式，还有虚拟IP地址和成员IP地址列表信息、转发成员信息等。同时，我们可以发现，这里面Forwarder 01的虚拟MAC地址和PCA上学习到的MAC地址相同，验证了每台路由器都对应一个虚拟MAC地址，并且使用虚拟MAC地址应答主机ARP请求的实现。

然后我们看一下VRRP1的接口MAC地址。

 

确认没有使用接口的真实MAC地址。

我们再看一下VRRP2设备上备份组的详细状态信息。

 

可以看到，虽然设备当前为VRRP备份组中的Backup路由器，但是转发器信息中，Forwarder 01和Forwarder 02的状态确是和VRRP1的状态相反。

接下来，我们在PCB和PCC的接口上也开启DHCP自动获取IP地址。

 

可以看到，PCB学习到的还是VRRP1的虚拟MAC地址。

 

而在PCC上，学习到的却是VRRP2的虚拟MAC地址。

接下来，我们在PCA、PCB和PCC上都开启长ping，测试到ISP的业务联通性，然后DOWN掉VRRP1的上行接口。

可以看到，报文转发甚至都没有出现波动。我们看一眼VRRP的状态。

 

可以看到，VRRP受Track联动的影响，已经切换为Backup状态，而两个转发器的状态都变成了Initialize状态，表示设备上VRRP备份组处于关闭状态。

然后我们查看PCA的ARP表项信息。

 

发现PCA的ARP表项并没有更新，那报文是怎么转发的呢？

 

从VRRP2上，我们可以看到，Forwarder 01的虚拟MAC地址后面有个Take Over的备注，说明VRRP2现在不仅可以响应原本自身的虚拟MAC地址的请求，还可以响应原本属于Master设备的虚拟MAC地址的请求，实现业务不中断转发。

好用吗？好像还可以，但是又没那么好用，正常情况谁会这么组网呢？