云网络环境大文件传输异常中断问题解析.pdf

云网络环境大文件传输异常中断问题解析

作者：王少峰

来源：《中国金融电脑》2017年第9期

一、问题描述

2017年4月，某商业银行数据中心测试云网络与传统网络环境服务器之间通过SCP方式

拷贝大文件，操作过程中出现间断性失败。具体故障表现为：传统网络环境中一台物理服务器

（IP地址简称为“A”）向测试云网络环境中一台虚拟机（IP地址简称为“B”）拷贝数据，

使用SCP拷贝一个200G左右大文件时出现异常中断，中断时间随机，部分数据拷贝无法正常

完成。

该测试云基于业界主流的网关+Spine+Leaf交换机组网方式，由20余台路由交换设备，3

台SDN控制器等设备组成。目前测试云架构如图1所示。

其中：

（1）VS1节点作为云网络环境出口，与传统网络交换核心设备互联互通。

（2）VS0节点作为整个测试云业务的三层网关，同时也是VXLAN网络的边界交换机，连

接SDN网络和传统网络。

（3）VS0和VS1之间逻辑上串联防火墙设备，对进出测试云的数据进行访问控制。

（4）VS0、SPINE节点和Leaf节点构成整个测试云SDN网络。Underlay平面通过三层

接口互联，运行OSPF动态路由；Overlay平面，运行VXLAN协议，VS0与Leaf节点作为

VXLAN的二层网关，承担VXLAN的封装、解封装。

（5）业务服务器直接连接到Leaf节点，其中，VS0与VS1节点为支持云网络架构的高端

型号交换机，通过机箱虚拟化技术（VirtualSystem）实现将一台物理设备虚拟成两个相互隔

离的逻辑系统。

二、原因分析过程

1.发现问题

（1）问题第一次出现时，在A服务器上，使用TCPDUMP命令抓包，发现A收到了一个源

地址为B发送的RST报文，TTL是253。初步确定是由于A服务器收到异常RST报文后中断

TCP链接导致大文件拷贝失败。

图2为A服务器收到的reset报文截图，其中sequencenumber内的4f41字段为探测

报文（详见下文）部分字段。

（2）由于该RST报文的TTL值是253，且源MAC是网关的MAC地址，网络人员初步怀

疑是防火墙在某种情况下发送该RST报文。4月12号晚上在Leaf节点连接A的物理接口

（抓包点1）以及防火墙和VS1之间的接口（抓包点2）采用端口镜像进行抓包，以确定该报

文是否是从防火墙外侧进入。抓包结果显示抓包点2没有抓到该RST报文，该RST报文是在

测试云内部网络产生的。

（3）在VS0和防火墙之间的抓包点（抓包点3），发现该抓包点和抓包点1都可以抓到

异常的RST报文，抓包点2情况和之前一样，无RST报文。同时监控防火墙会话信息和流量

统计，显示信息正常。

（4）为了排除防火墙因素，将防火墙做旁路（BYPASS）处理，测试发现拷贝异常中断的

情况仍然存在。此外，为避免交换机双机冗余设计（M-LAG）给问题排查带来影响，将VS0之

间的M-LAG机制断开，结果发现问题依旧。

（5）采用全端口镜像方式进行抓包并开启端口流量统计，发现该RST的源地址是SIPNE2

的地址，TTL为254，怀疑是Leaf交换机发出的该异常RST报文。

2.问题定位

为尽快定位问题，网络维护人员对问题涉及的各类网络设备配置、流量和日志等信息进行

了重新勘察，再次深入分析讨论，问题定位步骤如下：

（1）查看抓取到的报文，发现多出来的报文都有一个特征，在字段里面都有0x4f41，该

字段位于TCP头里面。该特征报文符合IP路径探测匹配的ACL，怀疑是Leaf交换机开启的IP

路径探测功能误抓报文导致。

（2）查看Leaf交换机底层ACL的命中情况，发现IP路径探测对应的ACL有多次命中的

情况。

如图3所示，类似于路径探测报文，该业务报文TCP头的Acknowledgmentnumber地段

内，实际值为图2服务器收到的reset报文截图4f41。

（3）继续分析抓取报文的处理，发现最终误抓的TCP报文被送到了CPU处理，根据标准

的TCP实现，收到没有建立s