XXX客户USG5320因链路负载分担配置不当导致业务中断的故障分析报告

发布时间:  2016-10-19 浏览次数:  114 下载次数:  0
问题描述

业务组网图:


业务简介:

各种业务都有,HTTPTCPUDPICMP

产品需求:

版本信息

USG5300 V100R003C01SPC900B075+V100R003C01SPH901

故障现象

10.13 17:00 割接上线后业务正常;

10.15早上8:30员工上班,8:30~9:00流量持续上涨,从监控软件看以往数据中心到园区业务最高流量1.5G,园区到数据中心业务最高流量0.8G

10.15早上11:20业务全部中断。

同时故障的时候

1)  ping FW不通

2)  telnet FW不通

3) 日志服务器接收不到日志





处理过程

故障分析

分析监控软件提取的上下行cisco交换机流量趋势图。数据中心侧cisco交换机在FWtrust域,园区侧交换机在untrust域。

上行数据中心cisco交换机两条千兆链路E2/35E2/36以及下行园区cisco交换链条千兆链路E2/35E2/36的收发报流量数据如下:

  


1、从流量数据分析,业务流量主要是数据中心发到园区的流量较大,两条链路之和峰值超过1个G,园区发送到数据中心的流量相对较小,两条链路峰值之和150M同时上下行链路报文转发负载并不均匀,从数据中心发往园区的1G流量全部从cisco2/36走。也就是从FW下行2GE口的其中一个接口走。这样导致FW单条GE口性能超过瓶颈。1GE口只能处理1G的流量,但是实际经过流量超过1G

2、对比上次割和这次割接的配置,这次割接的现场配置缺少了逐包负载分担的配置。默认配置下FWeth-trunk按照MAC进行HASH分担报文。跟客户确认,客户的组网中上下行只有路由器,对于FW来实际跑业务的只有两个MAC,在按MAC地址HASH分担报文的时候只会分担到一条链路上去,从而导致了FW负载分担不均,单条链路成为瓶颈。

3、在FW单条GE链路超过性能的前提下,CPU对于从超过性能的接口发送的报文会失败,然后又会进行重发试图再次发送。每个报文都会因为发送失败而重发。导致CPU的大量时间在处理重发 报文使得其他接口本来应该收上来的报文无法及时处理,导致出现故障的时候,客户pingtelnet不通FW,以及FW发送给日志服务器的日志发送不出来。这些现象的原因都是FW单个接口超过性能 后影响了其他接口的收发报文。

42015-10-15 11:23:19客户拔掉FW的一个接口试图下线FW墙,2015-10-15 11:23:34两个接口都被拔掉,FW彻底下线。从下面的日志看,FW
两个接口down掉之前,还有包过滤的匹配日志,说明当时防火墙还是有转发流量的,还有业务是通的,这点跟客户描述的全部业务中断是有差异
的,当时故障时应该还是有部分业务能够正常转发处理。






根因

此次该客户USG5320故障的原因是FWeth-trunk接口没配置逐包负载分担,在客户的网络中业务报文按MAC哈希到FW单条链路,流量超过GE口性能,导致业务转发异常。



解决方案

FW的两个eth-trunk配置逐包负载分担load-balance packet-all


现网数据和实验室测试对比

分析今天获取到的实际运行的现网流量数据,从数据中心到园区的下行流量峰值1.2G,平均报文长度1021字节,从园区到数据中心的上行流量峰值150M,平均报文长度157字节。

同时分析以往流量数据,从数据中心到园区的下行流量峰值1.5G,从园区到数据中心的上行流量峰值800M

对比我们实验室测试的接口性能数据,USG5320设备可以满足现网流量需求。





END