tcpdump - 蚂蚁网-多维人生，三实而立！

欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

Juniper IVE设备抓包方法

作者：易隐者发布于：2012-10-19 10:31 Friday 分类：参考资料

Juniper IVE VPN设备具有自带的抓包功能，在管理员登录上管理平台之后，在IVE设备管理界面的“Maintenance > Troubleshooting > Tools > TCP Dump”中可以看到相关的抓包设置选项，如下图所示：

这里的抓包设置选项都很简单，大家一看基本上都能明白，需要说明的是，这里的“Filter”设置选项，可以使用tcpdump的过滤语句对所需要捕获的报文进行过滤。

在点击“Start Sniffing”开启“TCP Dump” 抓包，在等待故障出现之后，可再次通过“Maintenance > Troubleshooting > Tools > TCP Dump”界面，点击“Stop Sniffing”，停止抓包，如下图所示：

在停止抓包之后，IVE会将捕获的数据报文保存为一个抓包文件，显示在“Dump file”界面下，如下图所示：

IVE保存的数据包文件提供三种格式文件的下载，分别为：Raw、SSL Dump、Human Readable（一般我们下载默认的“Raw”格式，因为Raw格式可以使用wireshark直接打开分析），我们点击“Get”，下载RAW格式的文件即可。

阅读全文>>

标签: TCP wireshark tcpdump 故障抓包 Juniper IVE troubleshooting

评论(0) 引用(0) 浏览(12380)

F5负载均衡抓包方法

作者：易隐者发布于：2012-10-17 12:48 Wednesday 分类：参考资料

登录F5

1，超级终端的登录：
通过Console电缆一端连接BIGIP，一端连接PC机的串口，然后打开超级终端，建立一个连接，超级终端中COM的参数设置如图：

不论是从Console口登陆，还是用SSH从网络登陆，BIG-IP的缺省登陆帐号与密码如下：
缺省登陆帐号：root
缺省登陆密码：default
输入帐号和密码后，将见到以下界面：

缺省的终端类型为vt100，回车后如图：

F5下的tcpdump的使用

1，web管理界面下的抓包
Tcpdump 工具在V4.5 之前只能在CLI 下使用，V9 提供了图形界面下的Tcpdump，在 System->support 界面下，我们可以直接使用tcpdump 工具：

2，F5命令行下Tcpdump的使用示例：
当业务无法正常工作时，经常需要在BIG-IP上抓包进行分析定位是什么原因导致数据包没有被常转发。BIG-IP上提供了TCPDUMP抓包分析工具。
TCPDUMP是Unix系统常用的报文分析工具，TCPDUMP经常用于故障定位，如会话保持失效、SNAT通信问题等。本文讲述TCPDUMP命令的基本用法，更详细的使用说明请参见“man tcpdump”。
命令语法：
       tcpdump [ -adeflnNOpqRStvxX ] [ -c count ] [ -F file ]
               [ -i interface ] [ -m module ] [ -r file ]
               [ -s snaplen ] [ -T type ] [ -w file ]
               [ -E algo:secret ] [ expression ]
其中：
 -i 报文捕获监听的接口，如果不指定，默认为系统最小编号的接口（不包括loop-back接口），一般对指定Vlan名称进行监控，如-i external 是对external vlan进行监控；也可以对指定端口进行监控如 –i 1.1。注意：当vlan 名称过长时，-i后面直接用vlan名称，tcpdump会出现错误提示，这时需要将vlan名改由vlan加vlan ID代替。如有一vlan名称为bip_external，vlan ID为2022，如要对bip_external vlan进行监听，需采用-i vlan2022的方式。
 -nn 不将IP地址或端口号转化为域名或协议名称
注：与BIG-IP 4.5版本的TCPDUMP命令不一样，在BIG-IP V9里面必须用两个nn才能使IP地址与端口不会被转化为域名或协议名称显示。
 -r 从文件中读取（该文件由-w选项创建）
 -s 确定捕获报文大小
 -w 直接将捕获报文写入文件，而不是对其进行解析并通过屏幕显示（与-r选项对应）
注：如果要将TCPDUMP所抓的包保存到文件，建议采用-s1600 –w /var/tmp/filename的方式，-s1600可以保证抓取完整的数据包，而/var/tmp使抓包文件保存在/var/tmp目录。

 -x 每个报文以十六进制方式显示
 -X 每个报文同时以文本和十六进制显示
 expression 匹配表达式的分组将进行解析。如果不指定表达式，系统对所有分组进行捕获分析。复杂表达式可以使用“and”与、“or”或以及“not”非操作进行组合。表达式有三种：
 type  三种种类：host、net和port。比如：host 10.1.1.1。如果不指定类型，默认为host。
 dir  有src、dst、 src or dst和src and dst四种方向。默认为src or dst，即双向。
 proto 常见协议有：ip、arp、tcp、udp、icmp等。如果不指定协议类型，默认为所有协议。
举例1：对external接口主机139.212.96.2并且端口为1433的流量进行监控。端口不指定tcp和udp，默认为同时对tcp和udp进行报文捕获。本命令不解析IP地址/端口号为主机名/服务名称，同时显示报文十二进制和文本信息，报文最大为1500字节。
f5-1:~# tcpdump -i external -nn -X -s 1600 port 1433 and host 139.212.96.2
tcpdump: listening on external
21:48:41.295546 139.212.96.2.1201 > 10.75.9.44.1433: . 302192826:302192827(1) ac
k 558871968 win 64360 (DF)
0x0000   012c 0800 4500 0029 38cf 4000 7f06 c3b2        .，..E..)8.@.....
0x0010   8bd4 6002 0a4b 092c 04b1 0599 1203 18ba        ..`..K.，........
0x0020   214f b5a0 5010 fb68 a926 0000 00               !O..P..h.&...
21:48:41.296015 10.75.9.44.1433 > 139.212.96.2.1201: . ack 1 win 64636 (DF)
0x0000   012c 0800 4500 0028 cb2d 4000 7f06 3155        .，..E..(.-@...1U
0x0010   0a4b 092c 8bd4 6002 0599 04b1 214f b5a0        .K.，..`.....!O..
0x0020   1203 18bb 5010 fc7c a812 0000 0000 0000        ....P..|........
0x0030   0000                                           ..
21:48:50.701130 139.212.96.2.1206 > 10.75.9.44.1433: . 304974934:304974935(1) ac
k 565108263 win 64882 (DF)
0x0000   012c 0800 4500 0029 38f7 4000 7f06 c38a        .，..E..)8.@.....
0x0010   8bd4 6002 0a4b 092c 04b6 0599 122d 8c56        ..`..K.，.....-.V
0x0020   21ae de27 5010 fd72 0a6b 0000 00               !..'P..r.k...
21:48:50.702567 10.75.9.44.1433 > 139.212.96.2.1206: . ack 1 win 65267 (DF)
0x0000   012c 0800 4500 0028 d3a6 4000 7f06 28dc        .，..E..(..@...(.
0x0010   0a4b 092c 8bd4 6002 0599 04b6 21ae de27        .K.，..`.....!..'
0x0020   122d 8c57 5010 fef3 08ea 0000 0000 0000        .-.WP...........
0x0030   0000                                           ..

举例2：对internal接口主机172.31.230.53和172.31.230.51之间端口8080的流量进行分组捕获。本命令不解析IP地址/端口号为主机名/服务名称，报文最大为1600字节，捕获信息以“/var/tmp/intdump”文件保存：
tcpdump -s 1600 -i internal -w /var/tmp/intdump　 host 172.31.230.53 and host 172.31.230.51 and port 8080
如果查看该捕获文件，请用tcpdump –r /var/tmp/intdump命令。也可以将捕获的文件下载下来用Ethereal工具解包分析。
Tcpdump的具体使用语法参见tcpdump使用手册

F5命令行下使用tcpdump的常见问题

1，对某一Virtual Server用TCPDUMP命令无法抓到包如何处理？
可能是该Virtual Server的属性中选用了Performance Layer4类型，导致数据包由四层加层ASIC芯片处理而没有流经CPU引起，碰到这种情况，选取该Virtual Server将type由Performance Layer4临时改为Standard再来用TCPDUMP命令抓包，抓包以后，改回到Performance Layer4。
2，TCPDUMP出现“truncated-ip - 1215 bytes missing!”信息是不是说明网络上有丢包？
在BIG-IP V9里面出现”Truncated-IP xxxx bytes missing”信息，一般来说并不是网络上有丢包引起的，而是在执行TCPDUMP命令时没有加上 –s0或-s1600参数时，而数据包大小超过TCPDUMP缺省的抓包大小（如果不加-s0或-s1600参数，则缺省的每个数据包只抓前面400byes），就会出现truncated-ip的情况。出现这种情况，只需要重新输入tcpdump命令，加上-s0或-s1600即可。
3，TCPDUMP 命令中的-i interface中的interface用VLAN名称（如external或internal）与接口编号（1.1或2.1）有什么区别？
如果采用VLAN名称作为-i的参数，TCPDUMP收集的数据包是经由内部接口到达TMM进程经由中央CPU处理的数据包。
采用VLAN名称作为-i参数的局限性在于，由于PVA四层加速芯片时位于BIG-IP的交换板(Swithboard)上，并不需要经由主机板与交换机板的内部接口到达中央CPU，因此TCPDUMP无法抓取这些四层加速的数据包。
因此采用VLAN名称作为-i的参数一般是用于对采用Standard作为Virtual Server类型的应用抓包时采用。

注：如果Virtual Server是用PVA四层加速芯片作加速处理，则在Virtual Server的属性中PVA Acceleration显示为Full。
（The PVA handles accelerated traffic in the following order:
• The PVA receives accelerated traffic from the switch subsystem
• The PVA transforms the packet in order to redirect the packet to the appropriate pool member
• The PVA sends the packet back to the switch subsystem
Fully accelerated traffic never reaches the internal trunk and is not processed by TMM. ）
如果采用接口编号作为-i的参数，则进出该接口的数据包将先被镜像给SCCP(SCCP是BIG-IP的管理子系统)，然后送到主机板上通过TCPDUMP抓包。由于是直接镜像了端口，因此经由四层加速芯处理的数据包也能被TCPDUMP获取。
采用接口编号作为-i的参数的局限性在于，由于数据包是经由SCCP（管理子系统）转发给主机板，数据包的处理速度有限，每秒只能处理200个数据包。因此采用接口编号作为-i的参数一般是用于做基本网络故障诊断时。
（When tcpdump is run on an interface， the packet is copied on switch ingress to the SCCP， which then sends it to the host to be captured by tcpdump.
Limitations
Running tcpdump on a switch interface is rate-limited to 200 packets per second. Therefore， if you run tcpdump on an interface that is processing more than 200 packets per second， the captured tcpdump file will not include all of the packets.
For example， the following command will capture PVA accelerated traffic， but the syntax will result in a rate limit of 200 packets per second。）
注：对于采用了PVA四层加速芯片加速处理的Virtual，而且网络流量又比较大时，如果需要进行抓包分析，建议在上一级交换机作端口镜像，将网络流量输出到外部的抓包主机上处理。

4，TCPDUMP 命令中出现“pcap_loop: Error: Interface packet capture busy”错误信息？
同时执行多个TCPDUMP，出现“pcap_loop: Error: Interface packet capture busy”错误，例如：
[root@bigip1:Active] config # tcpdump: listening on 1.1
[root@bigip1:Active] config # tcpdump -ni 1.3 -s 1600 -X -w/var/tmp/v741-E13.dmp port 22 &
[3] 6813
tcpdump: listening on 1.3
[root@bigip1:Active] config # tcpdump -ni 1.4 -s 1600 -X -w/var/tmp/v742-E14.dmp port 22 &
[4] 6820
tcpdump: listening on 1.4
[root@bigip1:Active] config # tcpdump: pcap_loop: Error: Interface packet capture busy
tcpdump: pcap_loop: Error: Interface packet capture busy
这种情况一般只发生在TCPDUMP -i参数采用接口编号时。原因主要在于当采用接口编号作为-i参数时，是通过BIG-IP的二层芯片将该接口的数据包镜像到中央CPU作处理。而BIG-IP的二层芯片的接口镜像功能不支持多个接口同时镜像，因此如果同时执行多个用接口名称作-i参数的TCPDUMP命令，就会出现Interface packet capture busy的信息。
注：对于采用VLAN名称作为TCPDUMP –i参数，则不存在这个问题，可以支持对多个VLAN同时执行TCPDUMP抓包命令。
(Currently only one tcpdump session is possible at a time on a switch interface (tcpdump on vlan alllows multiple sessons). This is due to a limitation of the Broadcom SDK， but we may be able to extend the SDK to support multiple sessions.
The root difficulty here is that mirrored packets don't carry a note saying "this is where I came from." In a Broadcom switch fabric we can mirror from multiple ports， and all the packets will funnel to the host -- but we don't know which tcpdump session to route them to. One idea involves a layer 2 lookup on each packet performed by the bcm56xx daemon on the sccp.　This would be intense so we continue to have this limitation.)

阅读全文>>

标签: 负载均衡 F5 tcpdump 抓包

评论(0) 引用(0) 浏览(55258)

【转】负载均衡故障诊断：一个MSS值引发的疑案

作者：易隐者发布于：2012-9-5 22:39 Wednesday 分类：案例讨论

【我的点评】：

1，此案例为服务器端系统异常MSS通告导致的业务应用故障，的确属于疑难故障范畴；

2，关于MSS的知识点，大家可参考本博客《TCP MSS与PMTUD》一文；

3，此案例充分证明，在遇到疑难故障时，站在原始报文交互的角度做深入的解码分析才是分析定位的根本之道；

4，此案例中，使用了正常时与异常时的对比分析法，关于对比分析法，大家可参考本博客《疑难网络故障的分析方法和原理之对比分析法》一文；

5，个人认为，此案例还可以做进一步的分析，如原作者开篇所言“很多东西都在互相影响”，既然经过负载均衡设备访问就出现这种问题，那么是否是负载均衡在发给服务器端的SYN报文跟客户端直接发给服务器端的SYN报文某些地方存在差异导致的呢？

【原文链接】：

http://virtualadc.blog.51cto.com/3027116/692407

【原文全文】：

负载均衡设备位于客户端和真实服务器之间，一旦访问发生问题，在客户经过简单诊断后，负载均衡设备往往会成为首要被怀疑的对象。客户一般这样质疑：为什么我直接访问服务器没有问题，通过你的设备访问就不行了呢？质疑的确实有道理，但大多数事情往往不是非一即二这样简单，有很多东西都在互相影响，这就使得真相迷雾重重。

某一天接到某客户报障，说是通过负载均衡设备访问某一业务的时候，页面无法打开或者等半天后只打开了部分页面，而客户端如果直接访问服务器，则可以顺利打开页面。

事情很明显，这中间肯定是有问题存在。登录负载均衡设备检查配置和log，并取一些内部诊断信息，没发现什么错误，只剩下唯一的办法：去客户现场抓包分析。

于是开始抓包，同时抓回了出现问题的服务的数据包和其他没有出现问题的服务的数据包。

经过分析，果然有所不同，下面是有问题的抓包内容（抓包1）：

10.52.127.108为客户端地址

10.0.1.112为VIP

10.0.1.99为真实服务器地址

由于是以旁路方式部署，需要转换源IP, 10.0.1.123为经过负载均衡设备转换的客户端地址（snat地址）

负载均衡的VIP配置为HTTP模式，这表示负载均衡设备是以proxy的方式来处理连接，也就是对每个连接，客户端先跟负载均衡设备完成一个三次握手，然后负载均衡设备再跟真实服务器完成一个三次握手。

访问流程：

1) 10.52.127.108访问10.0.1.112

2) 负载均衡设备与客户端完成三次握手

3）然后负载均衡设备把源IP: 10.52.127.108转换成10.0.1.123向服务器10.0.1.99发起连接

4）服务器10.0.1.99与负载均衡设备完成三次握手。

下图是访问没有问题的服务的抓包内容（抓包2）：

10.0.76.2为客户端地址

10.0.1.113为VIP

10.0.1.104为真实服务器地址

由于是以旁路方式部署，同样需要把客户端源IP转换为 10.0.1.123

访问流程跟抓包1相同。

仔细比较两个抓包内容，终于发现了差异出现在MSS值的协商上。

首先我们描述一下Client访问Server过程中MSS值的协行过程：

1）客户端在向服务器发出SYN包的时候，会带上客户端设备可以接受的最大MSS值，意思是服务器发送到客户端的每个包的内容大小都不能大于这个值。

2）服务器向客户端回复SYN,ACK包的时候，会比较客户端发来的MSS值和自己设定的MSS值，取两者的最小值作为自己可以接受的最大MSS值返回给客户端，意思是告诉客户端发送到服务器的每个包的内容大小都不能大于这个值。

3）在实际的传输中，双方往往会取二者中的最小值作为双方互相发送的包大小的最大值。

基于以上通信流程我们来分析一下以上的两个抓包内容：

抓包1：

客户端发出SYN包，标明自己可接受的最大MSS值为1460,负载均衡设备回应自己可接受的MSS值为1400,协商成功后，双方交互的包大小不会大于1400。

负载均衡设备向服务器发出自己的可接受MSS值为1380,服务器回应自己可接受的MSS值120,协商成功后，负载均衡设备发给服务器的包就不能大于120了。

问题正是出在最后跟服务器协商出的大小为120的MSS值上。

我们看到客户端向负载均衡设备发出的第一个请求包大小为905字节，这个包大小不大于1400，所以负载均衡设备接收到了，接着负载均衡设备要把该请求发给选定的服务器10.0.1.99，由于服务器可接收的包不能大于120,所以负载均衡设备只能把客户端发来的请求包分成八个小包发送给服务器，然后一些不可控制的问题就出现了，客户端发出请求包后，需要等待应答，但由于负载均衡设备把一个包分解成8个包后，使得负载均衡设备跟服务器之间的交互时间变长，这个过程中客户端可能会超时重发请求包，而负载均衡设备跟服务器之间那八个小包的处理还可能出现丢包，重传，重装等问题。最关键是客户端在该连接的所有请求发完后如果是发送一个RST包来关闭连接，那么即使该连接上还有内容没传输完，该条连接也会关闭，由于一个请求包分成太多的小包传输，一旦发生客户端发出RST包的这种情况，基本上都会导致数据不能传输完毕，以上种种原因导致了页面不能打开或者不能完全打开的现象。

我们再分析抓包2：

客户端发出SYN包，标明自己可接受的最大MSS值为1460,负载均衡设备回应自己可接受的MSS值为1400,协商成功后，双方交互的包大小不会大于1400。这一点跟抓包1相同。

负载均衡设备向服务器发出自己的可接受最大MSS值为1380,服务器回应自己可接受的MSS值1380,协商成功后，所以双方会以1380的MSS值互相通信。

无论是客户端跟负载均衡设备还是负载均衡设备跟服务器之间，都是一个请求一个应答就能完成交互，不会发生要把包分割的现象，所以不会出现抓包1所出现的问题。

网络通信中由于MTU的设置不当引发的问题屡见不鲜，比如在存在ADSL设备的情况下，如果把设备的MTU设置成1500, 往往客户端的访问会出现问题，这是因为ADSL的PPPoE协议在MTU中占去8个字节，也就是ADSL的MTU最大值最多为1492, 如果客户端跟服务器设的很大，传输的数据包恰好大于1492字节，将导致数据包不能通过。在程序设计中，程序所取MSS值往往是本机的MTU-40（TCP和IP头各占20个字节，MTU一般设成1500），所以基本上所有设备所能接受的最大MSS值不可能会大于1500-40=1460, 那么再考虑到网络中可能会存在PPPoE，VPN等设备会占用更多MTU字节，所以各家网络设备厂商提供的网络设备会进一步减小MSS值的设置，一般网络设备设定的MSS值大小为1400左右。

显然1400字节左右的MSS值是网络通信中的正常值，所以服务器返回一个120字节的MSS值这是一个不正常的现象，所以问题的根源在于服务器返回的MSS值不合适，那么这个值是谁返回的呢？是服务器，也就是说该返回哪个值主动权在于服务器，所以我们诊断问题原因出在服务器上。

接下来的处理需要去检查服务器为什么返回这个值，跟负载均衡设备无关了。但仍然有追踪的价值，因为服务器并不是一直返回120这个值，而是有些时候会协商成1380,这时候访问是正常的，有些时候是返回120，这时候就自然访问不正常。

客户的服务器装的是HP操作系统，应用软件是Oracle的ebs，在我们把问题定位到了服务器后，客户也找了HP的工程师来检查和分析，但无法找出原因。

个人分析问题原因可能出现在如下几个方面：

1） HP操作系统或者网卡驱动程序关于MTU的定义存在可变值，或者

2） Oracle ebs的底层通信程序在MSS值的协商时，会根据一些条件改变MSS值

以上仅仅是猜测，因为没有以上两个厂家的资深工程师的深度参与，无法最终定位结果，所以该问题成为了一个疑案。

阅读全文>>

标签: 疑难故障负载均衡 tcpdump MTU MSS 抓包 A10

评论(0) 引用(0) 浏览(11371)

FTP登陆故障分析

作者：易隐者发布于：2012-9-1 17:47 Saturday 分类：网络分析

【说在之前】：

1，此案例涉及到的分析方法，请大家参考本博客文章《疑难网络故障的分析方法和原理之对比分析法》；

2，此案例涉及到的知识点，请大家参考本博客的文章《应用层检测/深度包检测（DPI）》；

3，此案例中谈到的利用防火墙自带的抓包功能tcpdump的使用，请大家参考本博文章《天融信防火墙自带的tcpdump使用》一文，我曾将各种常见系统和网关设备自带的抓包功能的使用整理成《常见系统和网关设备自带抓包功能介绍及操作指南》一文，其他网关型设备自带的抓包功能的使用我会陆续择机发布到本博；

4，设备本身的BUG问题一般都属于疑难杂症级别，在做分析定位时，站在原始数据报文交互的角度抓包分析是比较靠谱的做法；

5，本故障还有另外一种解决的方法，给大家一点提示：ICMP重定向报文，感兴趣的兄弟自行思考，如需协助，可给我留言。

【我的案例】：

故障描述

1 故障拓扑

2 环境说明：

1、客户端的默认网关是主路由器；
2、主路由上设置了相应的策略，凡是FTP/HTTP的应用均交由备路由处理；
3、备路由上会将访问国家局的网段指向国家局路由；
4、核心与路由间均部署防火墙，防火墙工作在透明模式下；
5、客户端访问服务器的数据流走向比较复杂。

故障现象

1、省局到国家局的FTP服务很慢，一般需要40多秒才可以登陆上去，有时根本登陆不上去；
2、在故障机器上Ping国家局服务器，延时很小；
3、省局到国家局的HTTP应用正常。

故障分析

1 前期简单分析

1、Ping延时很小，说明网络层的延时很正常；
2、网络环境复杂，数据流走向复杂，数据包来回路径不一致，中间经过2台防火墙，可能存在状态检测的问题；
3、HTTP的数据流走向跟FTP的数据流走向应该是一样的，HTTP正常，FTP不正常，说明这个跟TCP的状态检测无关，应该是FTP应用层的问题。
暂时没什么头绪，只能先从客户端下手，进行抓包分析，看看大体的情况。

2 数据包分析

 登陆不上时的数据包分析
我们在客户端登录不上FTP服务器时，抓取其跟服务器交互的数据包，查看客户端与服务器的详细交互过程，如下图所示：

通过上图中针对每个交互数据包的详细分析和描述，我们基本上可以知道，在客户端登录不上FTP服务器时，是由于客户端与服务器交互用户名和密码时产生了问题，导致FTP登录时间过长，超出最大会话时间，从而被FTP服务器主动关闭。

 FTP登陆慢时的数据包分析

我们在客户端登录FTP服务器非常想缓慢时，抓取其跟服务器交互的数据包，查看客户端与服务器的详细交互过程，并针对每个交互的数据包做详细的说明和描述，如下图所示：

通过上图详细的分析，我们可以知道，产生较大延时的原因也是在用户名、密码交互的过程。
我们把上述两种场景下，客户端与服务器间用户名和密码交互的过程做一个示意图展现如下：

通过这个示意图，我们可以更加清楚的发现，之所以在客户端与服务器端交互用户名和密码时产生了很大的延时，是由于用户名和密码数据包在交互的过程中被中间设备丢弃导致的。
那么到底是哪个中间设备丢弃了FTP用户名和密码的数据包呢？接下来我们就要找出丢弃用户名和密码数据包的中间设备。

 定位丢包的中间设备

       在这个过程中，主要针对我们可以控制操作的中间设备进行排查，首先我们选择可能丢包的关键点。在这个网络环境下，我们首先考虑的就是2台防火墙设备。
       我们利用防火墙设备自带的tcpdump抓包功能，专门抓取FTP客户端与服务器交互的数据包（该抓包过程由于现场原因未作记录，在此无法做详细数据包展示），分析其过程，我们可以发现的确是防火墙丢弃了FTP用户名和密码数据包。
       那么防火墙为什么会丢弃FTP用户名和密码的数据包呢？
       抓包分析我们可以发现被丢弃的包都是FTP传输用户名和密码的包，这个肯定属于FTP应用层的包，防火墙丢弃FTP应用层的数据包，那么问题应该就出在防火墙的FTP应用层检测上。我们登陆上防火墙，查看防火墙针对FTP应用做了哪些应用检测的策略，结果我们发现，其针对FTP应用启用了应用层检测，如下图所示：