网络故障隐藏在人们肉眼看不到的地方，不易察觉。网络分析技术帮助运维人员从宏观世界走进数据包级的微观世界，如同披上斯科特.朗的战衣化身“蚁人”，通过对微观世界数据包级的统计分析，完成了对业务应用的故障分析定位，诠释网络故障分析的便捷和高效。

一、问题描述

某运营商采集机需要到支付平台FTP服务器提取文件，在提取文件时，经常发生采集脚本提取失败并停止运行的情况，通过总结失败文件，发现提取失败存在一定的规律，即文件名称结尾为“227”的文件在提取时都会失败。

二、应用访问网络路径

下图是和网络人员沟通的网络示意图，采集主机通过交换、路由、防火墙等网元设备，与支付平台FTP进行交易数据传输。由于故障现象是数据文件名称发生的变化导致采集脚本终止，定义为应用层的问题，我们注意力关注在防火墙等三层以上的设备上，固将抓包点分别放在了FW-1前、FW-2前、FW-3后，进行数据包分析。

三、分析过程

模仿之前故障现象进行测试，在支付平台上创建一个以“227”结尾的文件，例如“”的文件，同时在采集主机上运行脚本进行显示和采集。

从抓包点1、2上解码分析数据包payload，发现要显示的文件名称变为“TEST22_.”，如下图。这样判断故障点是在右侧，靠近支付平台这端。

同时，抓包点3上提取数据包进行解码分析，需要采集的文件名称仍为“.”，不会发生变化，如下图。

经过多次试验后发现，如果采集文件名称为“”，采集机通过FTP协议显示或提取就会变为“”，这时采集脚本会出现异常情况，造成停止运行，以后的数据文件不会被传送，从而产生数据积压。

四、分析结论

因此，综上可判断文件名称发生变化的节点在于抓包点2、3之间，也就是两道防火墙FW-2、FW-3，由于中间无法镜像流量，所以初步判断两台防火墙其中之一对FTP数据进行了修改。

通过其他部门沟通厂商分析配置并了解到，FW-3为Check Point防火墙，由于该防火墙开启了FTP检测，认为出现227（文件名称/文件大小）就是攻击行为FTP Bounce，导致出现文件名替换问题。

由于国外某著名防火墙厂商对于协议的安全检测选项，相比其他防火墙都要精细，在修改对于227的安全检测配置后，此类问题得到解决。

五、网络分析价值

由于网络架构不断发展升级，形式各样的应用故障总是层出不穷，应用访问要经过大量的中间设备，常规分析手段难以判断出现问题的节点。通过网络分析技术能做到2-7层解码，还原网络中最真实的数据，能够检测中间设备的异常传输，发现造成的应用异常的根本原因。