某项目中主备链路倒换缓慢的故障分析和处理

　　一、组网情况

　　如图所示为某运营商防火墙IMS项目其中一个局点的组网示意图，采用H3C公司F5000防火墙实现联网安全。由图可见，这是一个典型的双链路、双出口的组网模型，而且是使用OSPF多实例来实现全网互通。设备来自三个不同的厂商：城域网的两台接入设备是属于一个厂商，中间的两台安全设备是H3C的高端防火墙F5000-A5，局点内部的三台网络设备是另一个厂商的产品。

　　网络中采用如下方法学习和发布路由：

　　1、SBC如何去往城域网?

　　SBC通过配置两条缺省路由分别指内网—主和内网—备作为自己的主用网关和备用网关。

　　2、去往内部服务器的路由如何引入内网的OSPF 1?

　　内网—主和内网—备上分别配置去往服务器的静态路由，将静态路由引入OSPF进程。

　　3、内网设备如何知道怎么访问城域网?

　　在F5000上配置，让防火墙向OSPF 1内通告一条缺省路由，并通过设置不同的cost值来实现主备。

　　4、去往服务器IP地址的路由如何引入OSPF 2和城域网?

　　内部服务器使用的是私网地址，所以会在F5000上做NAT(静态NAT，以方便由外网访问内网服务器);然后在OSPF 2内引入静态路由，则做NAT的公网地址将被发布出去(做NAT时，无论是什么类型的NAT，网络设备会缺省为每个做NAT的公网地址产生一条静态路由。引入时，就是引入的这些静态路由。此静态路由均为黑洞路由，产生这种路由的目的是为了防止三层环路。)

　　二、故障现象

　　网络正常搭建之后，即是从内部服务器可以正常访问公网;公网地址也能主动访问服务器后，用户进行了主备倒换的测试。这时出现了问题：主备倒换缓慢，无法满足用户的要求。这里分成了好几种情况。第一种是我方防火墙shutdown端口时;第二种是我方设备重启后;第三种是内网—主的上行口shutdown时;第四种是内网—主设备重启时。

　　三、故障解决过程

　　1、我方防火墙shutdown端口时，切换缓慢，切换时间稳定在4—5s。

　　故障分析：down端口，连通性需要一段时间才恢复，基本可以判断是路由的问题(与防火墙做策略和控制是无关的，如果策略不正确应该一直不通才对)。问题的关键就集中到是内部路由还是外部路由出了问题?通过测试和观察内部—主、内部—备的路由表，发现内部路由很快就收敛了，则可以肯定是外部路由收敛缓慢造成。结合配置，OSPF的SPF算法使用的是最短的时间间隔，在这种网络规模中理应在很短时间内完成收敛;再考虑到OSPF dead时间为4s，因此联想到OSPF之所以收敛慢，是因为路由是借助OSPF邻居关系的超时机制来实现，而不是通过感知端口的状态。

　　通过与客户沟通，了解到F5000—主设备和接入—主间果然不是直连，因此感知不到端口的变化。

　　故障解决：采用BFD+OSPF联动，通过BFD的会话来检测端口状态，成功解决问题(研发人员提示：F5000使用BFD存在4个隐患，一般建议不要使用)。

　　2、F5000—主防火墙重启后丢包不稳定的问题。

　　故障分析：考虑到丢包的偶然性，初步判断不是设备造成此问题，而是协议造成，任何协议协商都有一个过程。结合防火墙的特性，联想到也许是受防火墙的影响：拒绝单向的访问，即使有相应的域间策略，也即是说受HA同步的影响。开启单向流检测功能，容许外部主动发送回应报文。

　　重新测试，发现仍然存在切换时间不稳定的问题。查看日志信息，发现F5000防火墙上行和下行的两个邻居关系建立的时间不一致，相差0—4秒。上行的邻居关系先建立，则数据包出去后回不来;下行的邻居关系先建立，则数据包根本出不去。

　　故障排除：通过静态路由解决协商不一致的问题，邻居关系未建立走静态路由;邻居关系建立后走动态路由。实现的方式是给静态路由指定优先级，OSPF外部路由的优先级为150，则指定静态路由的优先级为180。必须配置多条路由：向公网配置一条缺省路由;向内网配置几条具体路由。单向流检测功能也是需要开启的。

　　3、内网—主设备shutdown端口，主备链路切换不稳定、丢包1—5个。

　　故障分析：内网—主设备上行口down掉后，内部路由会很快收敛，则数据从备用链路出去，通过查看路由表可证明。既然数据可以出去，那就是说回不来了。通过观察状态，发现内网—主设备上行口down掉后，F5000防火墙的端口会有一定延迟。与研发沟通，这是防火墙内部工作机制的问题，防火墙以轮询的机制在检测端口状态(时间是在1—5秒内)导致路由收敛慢。

　　故障排除：对此故障无能为力，只能与客户沟通、协商，再就是等待研发推出新的系统版本或补丁。

　　4、内网—主设备重启后，主备链路切换时丢包较多，达6—8个。

　　故障分析：对F5000来说，它的下行口所连设备是shutdown端口，还是掉电重启，根本毫无不同。出现这个问题，应与重启设备本身相关，因为当时此设备有多块业务板卡，怀疑极有可能与各板卡启动时间不一有关。

　　故障排除：不幸中的万幸，SBC设备支持静态路由的延时切换功能，即当与SBC口相连接口up后，不是马上就进行切换，而是等待一个时间，等内网—主设备完全启动，然后切换。这样就可保证丢包在许可的范围内。

2016年01月