在昨天的文章（基础实验：VSR配置链路聚合）中，我们介绍到链路聚合实际上就是一种跨多个逻辑数据链路拆分、重组和排序数据报文的方法。结合前面的另一篇文章（在服务器集群中使用 IPv6 流标签进行负载均衡），文中介绍了负载均衡（Load Balance，LB）这种集群技术，它将特定的业务（网络服务、网络流量等）分担给多台网络设备（包括服务器、防火墙等）或多条链路，从而提高了业务处理能力，保证了业务的高可靠性。

其实，负载分配是一个比负载均衡稍微更笼统的术语，但负载均衡更常用。负载均衡技术一般分为服务器负载均衡和链路负载均衡，如文章（在服务器集群中使用 IPv6 流标签进行负载均衡）介绍的就是服务器负载均衡，本文要介绍的就是链路负载均衡。当然还有基于DNS的负载均衡、基于DHCP的负载均衡等等，不属于常用配置，就不再赘述了。

链路负载均衡中使用最多的就是出方向链路负载均衡，一般是指在内网用户访问外部互联网时，如果出口设备存在多条运营商链路，就可以通过负载均衡技术实现链路的动态选择，在多条链路上分担内网用户访问外部互联网的流量，从而充分利用多条链路，亦可以实现多链路主备的效果，提高可靠性。

这是我们上次测试的组网拓扑，在VSR2看来，两条链路都是可以用的，并且限速是在本地配置的，多少和实际情况有点出入，毕竟不是本地带宽敞开了用。

那我们在中间再串两台VSR进行限速，模拟运营商接入的场景，这样就能取消设备本地接口的限速了。

我们先配置VSR3的LR限速为100 Mbps，并配置PCA和PCB互访的路由通过VSR3，测试一下转发带宽。

qos lr outbound cir 102400

测得带宽为104 Mbps，基本满足要求。

再配置VSR4的LR限速为200 Mbps，并配置PCA和PCB互访的路由通过VSR4，测试一下转发带宽。

qos lr outbound cir 204800

测得带宽为207 Mbps，基本满足要求。

现在开始调整VSR2的负载均衡功能，为了配置此功能，假设VSR3接入的是联通100 M专线，VSR4接入的是电信200 M专线。对应的，调整PCB访问PCA流量的相关设备（VSR2、VSR3和VSR4）的上行接口全部开启SNAT功能。

创建负载均衡链路组lbg，创建负载均衡链路lbl1和lbl2，并加入链路组lbg。

#loadbalance link-group lbg transparent enable#loadbalance link lbl1 router ip 23.1.1.3 link-group lbg#loadbalance link lbl2 router ip 24.1.1.4 link-group lbg

链路负载均衡支持的虚服务器类型为link-ip，创建link-ip类型的虚服务器llb，配置其徐服务器IP地址为通配0.0.0.0/0，指定其缺省主用链路组为lbg，并开启此虚服务器。

#virtual-server llb type link-ip virtual ip address 0.0.0.0 0 default link-group lbg service enable

我们先看一下负载均衡链路的状态。

发现此时的状态是unknown，并且要测试只是可以ping通，但是打流是打不了的。

我们为负载均衡链路加上健康检测机制。

#nqa template icmp lb reaction trigger per-probe#loadbalance link lbl1 success-criteria at-least 2 probe lb#loadbalance link lbl2 success-criteria at-least 2 probe lb

再次查看负载均衡链路的状态。

状态OK了。现在测试一下带宽效果。

测得的带宽为205 Mbps，我们从VSR2上看一下。

可以看到，负载均衡日志显示第一个源端口是44812的报文先是命中了默认的负载均衡组，然后命中了链路lbl1，并转发了出去。但是巧的是，iperf紧接着又发了一个源端口是44814的报文，这次就命中了链路lbl2。这样一来，最后测得的带宽就是链路lbl2的带宽200 Mbps了。

要不说负载这事看运气呢，再测一遍，这次的带宽就是103 Mbps了。

查看日志，可以看到过程跟上一次反过来了。

接着，我们再把打流线程数设置为20，看一下带宽情况。

Nice，成了！带宽是309 Mbps。

怎么样，带宽是不是达到两条线路的总和300 Mbps了？这下你知道怎么充分利用多条出口线路了吧？

最后，我们持续打流1分钟，看到负载选路情况之后断掉当前链路，模拟测试一下业务中断的情况。

额。。。断开之后测试连接会被重置。那就用ICMP代替一下吧。

可以看到，接口于37秒DOWN掉，在39秒时检测到接口状态异常，耗时2秒，这个时间间隔是由命令success-criteria at-least 2调整的，NQA探测每秒一次，2次就是2秒。紧接着触发重新调度，并且丢弃到转发异常的报文，等待源主机重新发起请求，最后再41秒完成新的负载分担。

从主机侧，我们可以看到，丢包数量为4个，和负载均衡过程相同