在前面的文章中，我们知道了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地址的请求，实现业务不中断转发。
好用吗？好像还可以，但是又没那么好用，正常情况谁会这么组网呢？
