vrrp配置-网络之路31：配置VRRP多备份组负载分担

正文共：1888 字 11 图，预估阅读时间：2 分钟

目录

%IGnoRe_pRe_1%

%IGnoRe_pRe_2%

%IGnoRe_pRe_3%

%IGnoRe_pRe_4%

%IGnoRe_pRe_5%

%IGnoRe_pRe_6%

%IGnoRe_pRe_7%

%IGnoRe_pRe_8%

%IGnoRe_pRe_9%

%IGnoRe_pRe_10%

%IGnoRe_pRe_11%

前面我们介绍了VRRP（），两台设备之间处于主备关系。也就是说，当主设备故障之后，流量才会切换到备设备上。这种使用方式一定程度上讲，不太符合经济适用的原则，我们前面介绍过链路聚合（、）、负载均衡（）和策略路由（）等等，都是为了在提高可靠性的同时尽可能的提高转发性能。如果不使用VRRP，我们仍然可以使用策略路由实现两台设备的主备，针对VRRP单备份组和策略路由之间主备切换的差异，我们也做了单独介绍（）。

如果使用策略路由，则可以轻松配置主备设备之间的流量负载；但是策略路由是通过周期性地查询FIB表中是否存在下一跳地址对应的条目，来判断设置的报文转发下一跳地址是否可用的，当设备到下一跳的路径发生变化时，策略路由无法及时感知，可能会导致通信发生短暂中断。我们通过不断地配置、调整nQa检测，最终的切换时间还是不能很好地控制在10秒以内，对业务影响可能会比较大。

6.6、配置VRRP多备份组

那有没有稍微好一点的实现方法呢？

有的！单备份组VRRP解决不好的问题，我们交给多备份组VRRP来试一下！

组网需求

1、核心交换机cORESW与VRRP备份组之间通过10.1.1.0/24网段进行互通；

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

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

4、实现Pca可以持续访问ISP的业务地址8.8.8.8。

组网图

VRRP多备份组配置组网图：

实验环境

%IGnoRe_pRe_12%

配置步骤

在配置VRRP单备份组时（），VRRP的虚拟IP地址、VRRP主备路由器的接口真实IP地址都是配置在相同网段的，通过调整成员在备份组中的优先级来实现主备设备的选举。

而VRRP多备份组的实现机制也是一样的，只需要配置一个和既有VRRP备份组不冲突的备份组号和虚拟IP地址，再配置好成员在备份组中的优先级就可以了。例如在备份组10中，VRRP1和VRRP2的VRRP备份组相关配置如下：

VRRP1备份组10

%IGnoRe_pRe_13%

VRRP2备份组10

%IGnoRe_pRe_14%

而在备份组20中，VRRP1和VRRP2的VRRP备份组相关配置如下：

VRRP1备份组20

%IGnoRe_pRe_15%

VRRP2备份组20

%IGnoRe_pRe_16%

同时我们把策略路由的配置也结合起来，在cORESW设备的Pca网关下面，配置策略路由vRRp，策略路由配置为匹配所有转发流量，策略路由的动作配置为负载分担模式，应用的下一跳分别为VRRP备份组10和备份组20的虚拟IP地址。

%IGnoRe_pRe_17%

此时，流量的负载分担由策略路由实现，设备的主备由VRRP实现，我们也无需再配置nQa探测了。设备的完整配置如下：

VRRP1

%IGnoRe_pRe_18%

VRRP2

%IGnoRe_pRe_19%

cORESW

%IGnoRe_pRe_20%

ISP

%IGnoRe_pRe_21%

验证配置

测试从Pca到ISP的业务联通性。

业务访问正常，看一下流量的转发路径。

可以看到，流量成功负载到了两个VRRP的备份组上，但是显示的IP地址是接口的真实IP地址。我们看一下VRRP1设备上备份组的详细状态信息。

可以看到，VRRP的工作模式为StandaRd标准协议模式，存在的备份组数目为2，都在接口GIGaBItEtHERnet0/0下面，VRRP1在备份组10中的角色是MasteR，备份组的虚拟IP地址为10.1.1.1，可以看到备份组虚拟IP地址对应的虚拟mac地址、对应接口的主IP地址等信息；VRRP1在备份组20中的角色是Backup，备份组的虚拟IP地址为10.1.1.2，没有显示备份组虚拟IP地址对应的虚拟mac地址，对应接口的主IP地址是VRRP2设备的接口IP地址。

接下来，我们在Pca上开启长ping，分别DOWn掉VRRP1和VRRP2的下联口，查看一下业务中断情况。

可以看到，DOWn掉VRRP1的下联口时，出现了一个丢包，这个勉强还是可以接受的。接着我们DOWn掉VRRP2的下联口。

此时的丢包就比较严重了，又是11个包，这个就有点不能接受了。经过分析，发现出现了短暂的VRRP报文交互“异常”，DOWn掉VRRP1的下联口之后，再次使能接口时，VRRP1在两个备份组内都是MasteR角色。

原因是VRRP1在备份组20中的masteR_down_TimeR计时器超时，快速切换到将MasteR角色，同时将adveR_TimeR设置为adveRtisement_inteRval，在这个时间段内，即使设备端口恢复，在adveR_TimeR的时间周期内，也不会向外发布VRRP通告报文。这部分的详细实现请参考RFc文档（）的第6章节状态机切换。

同时，VRRP2在两个备份组内都是MasteR角色。

原因是VRRP2在备份组10中收到了优先级为零的VRRP通告报文，快速切换到将MasteR角色，同时将masteR_down_TimeR计时器设置为skew_Time。抓包看就是这样：

但是等待时间不应该这么长，我就看了一下交换机的接口状态。

可以看到，我们在模拟接口闪断之后，交换机的互联口切换到了DIScaRDInG状态，然后经过大约31秒，接口才经LEaRnInG状态切换为正常的FORWaRDInG状态。那我们把接口配置成边缘端口试一下。

然后就能看到接口UP之后，VRRP1很快抢占回MasteR了。

所以，配置VRRP多备份组来实现设备的主备，同时配置策略路由来实现流量在不同备份组之间的负载分担是基本可行的。

长按二维码