交换机CE6851HI(V200R001SPC700)Linux系统SCP命令传输大文件随机中断

发布时间:  2017-04-22 浏览次数:  149 下载次数:  0
问题描述

某金融客户数据中心反馈其新建测试云网络中采样SCP拷贝大文件无法成功,具体情况如下:从上海传统网络一台物理服务器192.168.1.1(示例)向北京测试云网络中一台虚机192.168.1.2(示例)拷贝数据,使用Linux系统服务中的命令SCP拷贝一个30G左右大文件,会出现异常中断,中断时间随机,影响数据拷贝。

告警信息

在文件传输过程中,上海端服务器192.168.1.1会报connection rest by peer的现象,同时文件传输失败。

处理过程

1)      问题出现时,在192.168.1.2服务器上,使用TCPDUMP命令抓包,发现192.168.1.2收到了一个源地址为192.168.1.1发送的RST报文,但是TTL却是253。初步确定是由于192.168.1.2服务器收到异常RST报文后中断TCP链接导致大文件拷贝失败。

2)      由于该RST报文的TTL值是253,并且源MAC是网关VS0MAC地址,怀疑是防火墙在某种情况下发送该RST报文,在6851Leaf节点设备上连接192.168.1.2的物理接口(抓包点1)以及防火墙和VS1之间的接口(抓包点2)采用端口镜像进行抓包,以确定该报文是否是从防火墙外侧进入。抓包结果显示抓包点2没有抓到该RST报文,该RST报文是在测试云内部网络产生的。同时收集防火墙配置信息与诊断信息,提供给防火墙研发分析。

3)      VS0和防火墙之间增加了一个抓包点(抓包点3),发现该抓包点3和抓包点1都可以抓到异常的RST报文,抓包点2情况和之前一样,无RST报文。同时监控防火墙会话信息和流量统计,显示信息正常。

4)      为了排除防火墙因素,BYPASS防火墙,测试发现拷贝异常中断的情况仍然存在。为了排除M-LAG影响,将两台VS0之间的M-LAG断开,发现问题依旧。

5)      采用全端口镜像方式进行抓包,并开启端口流量统计,发现该RST的源地址是SIPNE2的地址,TTL254,怀疑是Leaf交换机发出的该异常RST报文。同时,协调CE交换机研发到现场进行问题处理。
6)      查看抓取到的报文,发现多出来的报文都有一个特征,在字段里面都有0x4f41,该字段位于TCP头里面。该特征报文符合Agile Controller 控制器IP路径探测功能匹配的ACL,怀疑是Leaf交换机开启的IP路径探测功能误抓报文导致。
7)      查看Leaf交换机底层ACL的命中情况,发现IP路径探测对应的ACL有多次命中的情况。


8)      继续分析抓取报文的处理,发现最终误抓的TCP报文被送到了CPU处理,根据标准的TCP实现,leaf交换机收到没有建立sessionTCP报文则会判断为攻击报文,需要主动发reset报文。发送的reset报文是根据收到的报文,交换源、目的IP,源、目的端口号,默认字节长度发回去。
综上分析,该问题定位,是由于Leaf交换机的IP路径探测功能误抓取了正常的TCP数据流报文并进行了错误处理导致。

根因

1)      192.168.1.2服务器发送的TCP报文(TCP头偏移8个字节为4f41的报文,该位置是Acknowledgment number)经过Leaf交换机时,匹配了路径探测功能的ACL,被上送到CPU并进入TCP协议栈进行处理

2)      TCP协议栈发现该报文无法命中当前系统的任何一个TCP会话,误以为是TCP攻击报文,主动回应了TCP reset报文,交换了源、目的IP和端口号,同时TCP头里Sequence number里包含4f41

3)      TCP RESET报文最终被转发到192.168.1.2服务器,导致192.168.1.2拆除192.168.1.1和其之间建立的SCP会话,最终导致SCP拷贝大文件异常中断。

解决方案

该问题已经在补丁中解决,设备载V200R001SPH006该补丁后,针对SCP传输大文件进行多次验证,都传输成功,问题解决。

END