我们在EVE-NG模拟器中，对基于VPN虚拟链路的负载分担进行了初步配置和简单测试，但是受限于EVE-NG模拟器的稳定性问题，最终没有实现既定的测试目标。
所以，我又在VMWare中把实验环境重新部署了一遍，争取完成测试目标。
组网拓扑和之前的基本相同，VSR2用于模拟公网环境，避免隧道两端直连；VSR1作为本地主机PC的网关设备，穿越VSR2设备，和VSR3建立GRE隧道，和VSR4建立L2TP隧道，和VSR5建立IPsec隧道。
VMWare ESXi 6.7.0（ProLiant DL360 Gen9，48核心，128G内存）
H3C VSR1000（Version 7.1.064, Release 1340P16，4核心，8G内存）
CentOS 7.9.2009（测试用虚拟机，4核心，4G内存）
按照实验组网重新配置设备，同时在VSR1上基于3条VPN隧道配置链路负载均衡。各设备配置如下。
#sysname VSR1#nqa template icmp lb reaction trigger per-probe#interface Virtual-PPP4 ppp chap password simple lb ppp chap user lb ppp pap local-user lb password simple lb ip address ppp-negotiate l2tp-auto-client l2tp-group 4 nat outbound#interface GigabitEthernet2/0 ip address 12.1.1.1 255.255.255.0#interface GigabitEthernet3/0 ip address 11.1.1.1 255.255.255.0#interface Tunnel3 mode gre ip address 13.1.1.1 255.255.255.0 source 12.1.1.1 destination 23.1.1.3 nat outbound#interface Tunnel5 mode ipsec ip address 15.1.1.1 255.255.255.0 source 12.1.1.1 destination 25.1.1.5 nat outbound tunnel protection ipsec profile lb#ip route-static 0.0.0.0 0 12.1.1.2#ipsec transform-set lb esp encryption-algorithm des-cbc esp authentication-algorithm sha1#ipsec profile lb isakmp transform-set lb ike-profile lb#l2tp-group 4 mode lac lns-ip 24.1.1.4 undo tunnel authentication tunnel name LAC#l2tp enable#ike profile lb keychain lb#ike keychain lb pre-shared-key address 25.1.1.5 255.255.255.255 key simple lb#loadbalance link-group lbg transparent enable#virtual-server llb type link-ip virtual ip address 0.0.0.0 0 default link-group lbg service enable#loadbalance link lb3 router ip 13.1.1.3 link-group lbg success-criteria at-least 2 probe lb#loadbalance link lb4 router ip 14.1.1.4 link-group lbg success-criteria at-least 2 probe lb#loadbalance link lb5 router ip 15.1.1.5 link-group lbg success-criteria at-least 2 probe lb
#sysname VSR2#interface GigabitEthernet2/0 ip address 12.1.1.2 255.255.255.0#interface GigabitEthernet3/0 ip address 23.1.1.2 255.255.255.0#interface GigabitEthernet4/0 ip address 24.1.1.2 255.255.255.0#interface GigabitEthernet5/0 ip address 25.1.1.2 255.255.255.0
#sysname VSR3#interface GigabitEthernet2/0 ip address 23.1.1.3 255.255.255.0#interface GigabitEthernet3/0 ip address 36.1.1.3 255.255.255.0 nat outbound#interface Tunnel3 mode gre ip address 13.1.1.3 255.255.255.0 source 23.1.1.3 destination 12.1.1.1#ip route-static 12.1.1.0 24 23.1.1.2ip route-static 66.1.1.0 24 36.1.1.6
#sysname VSR4#interface Virtual-Template4 ppp authentication-mode pap chap remote address 14.1.1.1 ip address 14.1.1.4 255.255.255.0#interface GigabitEthernet2/0 ip address 24.1.1.4 255.255.255.0#interface GigabitEthernet3/0 ip address 46.1.1.4 255.255.255.0 nat outbound#ip route-static 12.1.1.0 24 24.1.1.2ip route-static 66.1.1.0 24 46.1.1.6#local-user lb class network password simple lb service-type ppp#l2tp-group 4 mode lns allow l2tp virtual-template 4 remote LAC undo tunnel authentication tunnel name LNS#l2tp enable
#sysname VSR5#interface GigabitEthernet2/0 ip address 25.1.1.5 255.255.255.0#interface GigabitEthernet3/0 ip address 56.1.1.5 255.255.255.0 nat outbound#interface Tunnel5 mode ipsec ip address 15.1.1.5 255.255.255.0 source 25.1.1.5 destination 12.1.1.1 tunnel protection ipsec profile lb#ip route-static 12.1.1.0 24 25.1.1.2ip route-static 66.1.1.0 24 56.1.1.6#ipsec transform-set lb esp encryption-algorithm des-cbc esp authentication-algorithm sha1#ipsec profile lb isakmp transform-set lb ike-profile lb#ike profile lb keychain lb#ike keychain lb pre-shared-key address 12.1.1.1 255.255.255.255 key simple lb
#sysname VSR6#interface GigabitEthernet2/0 ip address 36.1.1.6 255.255.255.0#interface GigabitEthernet3/0 ip address 46.1.1.6 255.255.255.0#interface GigabitEthernet4/0 ip address 56.1.1.6 255.255.255.0#interface GigabitEthernet5/0 ip address 66.1.1.1 255.255.255.0 nat outbound
我们首先测试一下非限速状态下的打流速率。
可以看到，远远高出EVE-NG的150Mbps速率，达到了3.36 Gbps。
接下来我们给3条VPN隧道配置限速。配置VSR1和VSR3建立的GRE隧道的限速为100 Mbps。
配置VSR1和VSR4建立的L2TP隧道的限速为200 Mbps。
配置VSR1和VSR5建立的IPsec隧道的限速为50 Mbps。
配置的过程中，设备的负载均衡链路比较稳定，始终没有出现UP/DOWN的情况，直接测试负载的总带宽，得到结果为351Mbps，和3条VPN隧道的带宽之和相同，堪称完美。
然后测试一下链路主备的效果。前面我们已经知道iperf3在打流时会先建立TCP连接或UDP连接，如果中间断开选中的负载链路，及时配置了重定向连接来把连接重定向到链路组中其它可用的链路上，iperf3也不会自动重新建立连接。所以本次我们直接用ping来测试。
可以看到，第一次是负载到了lb4链路上，断开该链路之后，重新负载到了lb3链路上。
中断时间8秒，从日志中可以看到，probe探测是5秒钟一次，在lb4链路探测成功后的下一次探测中没有收到响应报文，随即在3秒后再次探测，探测失败，同时报告lb4链路失效，触发重定向，将链路负载到lb3链路。
紧接着我们又断开了lb3链路，重复上一个流程，将链路重定向负载到lb5链路。
那有没有办法压缩重定向的时间来减少故障时间呢？
肯定有啊，我们配置的健康探测是通过引用NQA模板实现的，在NQA模板视图下，测试中连续两次测试开始时间的默认时间间隔为5000毫秒，而支持的配置范围是0-604800000毫秒。（注意：时间间隔为0，表示两次测试的时间间隔为无穷，即只进行一次测试，此时不会生成统计结果。）
所以，我们只要将时间间隔调小就可以了，先调成500毫秒测试一下。
然后我们就发现了，第一次探测失败是在22:41:38:941，报告链路探测失败是在22:41:41:943，间隔3秒，中间探测了6次；22:41:43:744报告链路故障，并触发重定向，耗时2秒；然后新的报文在22:41:44:744命中新的链路。总耗时6秒，丢包6个。
诶，这个时间还是稍微有点长啊，像之前使用物理线路，端口DOWN了直接就触发了，但是虚拟链路不一样，链路探测还要一定时间，导致中断时间稍长。
推荐本站淘宝优惠价购买喜欢的宝贝:
本文链接：https://hqyman.cn/post/9911.html 非本站原创文章欢迎转载，原创文章需保留本站地址！
微信支付宝扫一扫，打赏作者吧～休息一下~~
萌ICP备20248119号
