【案例分享】应用负载（AD）对接OSPF最佳实践

本贴主要介绍了负载对接OSPF的主要配置、实现原理以及测试结果，希望看到本贴的小伙伴能够少踩坑，提升一些测试的效果。

【测试背景】

目前金融行业客户使用负载场景较多，有一部分客户有使用OSPF的需求。金融客户一般要求负载能够和客户的核心设备OSPF对接，并且保证因故障导致设备切换时间很短。

【测试版本】

AD7.0.26版本

【测前须知】

1、建议负载部署模式：集群模式

集群模式，两台或以上的负载同时和客户核心三层设备建立OSPF邻居，客户核心设备学习到的路由为等价路由，故障一台设备可以通过另一条路由快速恢复业务，最终呈现出来的效果是不会丢包或者仅丢1个包。

不推荐负载主备模式，如果是主备模式做主备切换，相当于是备机重新协商OSPF邻居，协商时间+路由收敛时间就比较长了，所以不推荐此方式。

2、测试应用负载

集群模式的虚拟服务（VS）可以选择运行位置，可以选择运行在集群的位置。本次测试选择了只运行在一台主机上，这样可以清晰的看出切换时发生的路由变化。

3、为保证OSPF切换效果，修改OSPF的hello时间，修改为2秒（默认10秒），同时dead时间改为8秒（默认40秒）。

注意：修改hello时间或者dead时间OSPF邻居会建立失败，交换机修改hello时间会自动修改dead时间。

【测试方案】方案一、深信服应用负载集群模式+核心交换机堆叠模式

负载集群中的2台主机分别与核心交换机集群建立OSPF邻居。

这种场景下可以使用P2P的网络结构建立邻居，可以最大程度的减少邻居数量以及路由条目，增加路由收敛速度。

方案二、深信服应用负载集群模式+核心交换机m-lag模式

负载集群中的2台主机分别与2台核心交换机建立OSPF邻居。

如果交换机使用m-lag模式部署，实际上建立OSPF邻居的设备就是4台，这种场景无法使用P2P的网络结构建立邻居，只能用broadcast，建立OSPF全连接的邻居，这种情况就会出现邻居数量以及路由条目较多的情况。

注意：目前金融行业客户很少有使用交换机堆叠跑核心业务，具体原因还是可靠性差一些，具体测试方案可以根据实际情况自行选择。

【测试配置】方案一、核心交换机做堆叠

使用模拟器模拟测试方案一的环境：

方案二、核心交换机做M-LAG

使用模拟器模拟方案二的环境：

【测试过程】一、核心交换机做堆叠测试过程1、邻居状态

AD-Master的OSPF邻居：

AD-Backup的OSPF邻居：

IRF的OSPF邻居

2、路由学习情况

AD-Master的OSPF路由：

AD-Backup的OSPF路由：

IRF的OSPF路由

3、测试过程以及结果

测试目的	测试设备是否支持管理页面非抢占模式下切换应用组主设备
测试步骤	1、 测试虚拟机长ping 应用的VIP； 2、 登录应用组主设备Web进行应用组主设备切换； 3、 检查长ping丢包情况，检查应用组主设备切换是否正常； 4、 测试完成后回切。
预期结果	应用组主设备正常切换，长ping少量丢包。
测试结果 (测试截图)	步骤1：测试虚拟机长ping应用的VIP； 初始状态下应用组主设备为master节点 步骤2：登录应用组主设备Web进行应用组主设备切换 将应用组主设备切换为backup，提交等待会话同步正常 步骤3：检查长ping丢包情况，检查应用组主设备切换是否正常 测试结果长ping未丢包 步骤4：测试完成，将应用组主设备回切至Master，应用组设备与长ping未丢包。
测试结论	√通过 ▢不通过
备注

测试目的	测试设备在业务线缆断开后，应用组主设备能否正常切换
测试步骤	1. 测试虚拟机长ping 测试应用的VIP； 2. 手动禁用AD（master）的物理接口；（因为开启了插拔网线检测，这样测试效果最好） 3. 检查长ping丢包情况及应用组主设备是否发生切换； 4. 测试完成后开启AD（master）的物理接口。
预期结果	应用组主设备正常切换，长ping少量丢包。
测试结果 (测试截图)	步骤1：[size=9.0000pt]终端长ping [size=9.0000pt]测试[size=9.0000pt]应用的VIP[size=9.0000pt]如图 步骤2：手动禁用AD（master）的物理接口； 步骤3：检查长ping丢了4个包，应用组主设备自动切换到了backup 步骤4：测试完开启AD（master）的线路，未开启抢占，应用组不会切换。
测试结论	√通过 ▢不通过
备注	丢包4个的原因： AD-Master设备互联接口关闭后，AD-Backup设备协商为主机，重新发布一条路由，但原有路由并未消失，数据流依然会匹配到第一条路由，只有等到第一条路由失效后业务才会正常大约为dead时间。（目前设置的8秒），这里目前没有太好的解决办法，目前好像只能期待BFD功能快速上线了。

二、核心交换机做M-LAG测试过程1、邻居状态

AD-Master的OSPF邻居：

AD-Backup的OSPF邻居：

M-LAG-1的OSPF邻居：

M-LAG-2的OSPF邻居：

2、路由学习情况

AD-Master的OSPF路由

AD-Backup的OSPF路由

M-LAG-1的OSPF路由

M-LAG-2的路由

3、测试结果

测试目的	测试设备是否支持管理页面非抢占模式下切换应用组主设备
测试步骤	1、 测试虚拟机长ping 应用的VIP； 2、 登录应用组主设备Web进行应用组主设备切换； 3、 检查长ping丢包情况，检查应用组主设备切换是否正常。 4、 测试完成后回切
预期结果	应用组主设备正常切换，长ping少量丢包。
测试结果 (测试截图)	步骤1：测试虚拟机长ping应用的VIP； 初始状态下应用组主设备为master节点 步骤2：登录应用组主设备Web进行应用组主设备切换 将应用组主设备切换为backup，提交等待会话同步正常 步骤3：检查长ping丢包情况，检查应用组主设备切换是否正常 测试结果长ping未丢包 步骤4：测试完成，将应用组主设备回切至Master，应用组设备与长ping丢包情况如图。
测试结论	√通过 ▢不通过
备注

测试目的	测试设备在业务线缆断开后，应用组主设备能否正常切换
测试步骤	1、 测试虚拟机长ping 测试应用的VIP； 2、 手动禁用AD（master）的物理接口；（因为开启了插拔网线检测，这样测试效果最好） 3、 检查长ping丢包情况及应用组主设备是否发生切换； 4、 测试完成后开启AD（master）的物理接口。
预期结果	应用组主设备正常切换，长ping少量丢包。
测试结果 (测试截图)	步骤1：[size=9.0000pt]终端长ping [size=9.0000pt]测试[size=9.0000pt]应用的VIP[size=9.0000pt]如图 步骤2：手动禁用AD（master）的物理接口； 步骤3：检查长ping丢了1个包，应用组主设备自动切换到了backup 步骤4：测试完开启AD（master）的线路，未开启抢占，应用组不会切换。
测试结论	√通过 ▢不通过
备注	由于应用组未启用抢占，因此生效设备仍然在Backup。 之前先测试的方案二再测试方案一，但是堆叠的情况下会丢包，于是又重新测试了业务都运行在备机的情况下插拔网线回切，备机回切主机时会丢4个包，原因和堆叠一样。

【测试结论】

深信服负载在集群模式对接核心交换机的OSPF效果还是比较好的，不管核心交换机是堆叠还是M-LAG，在负载的界面上做主备切换的操作都不会丢包。

但是做线路故障测试的过程中发现了一个问题：新发布出来的路由不会被优先选择的。后续如果负载支持了BFD功能，测试效果会更加的好。

【其他】

本次实验模拟环境是华三的HCL，负载使用的vAD 7.0.26版本（先安装vAD7.0.8R7再升级），如果对这个测试感兴趣的小伙伴也可以自行做一做实验，如果对交换机的命令不熟悉也可以私信我获取交换机的相关配置哦~

逐句地看完这个帖子以后，我的心久久不能平静，震撼啊!为什么会有如此好的帖子!我纵横社区多年，自以为再也不会有任何帖子能打动我，没想到今天看到了如此精妙绝伦的这样一篇帖子。

逐句地看完这个帖子以后，我的心久久不能平静，震撼啊!为什么会有如此好的帖子!我纵横社区多年，自以为再也不会有任何帖子能打动我，没想到今天看到了如此精妙绝伦的这样一篇帖子。