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

       由于故障现场环境的复杂性、设备的多样性、系统本身的不稳定性以及网络运行情况的不确定性，一个故障的产生，可能存在各种各样的原因，有些甚至超乎我们平日的想象。而我们在遇到疑难故障时，经常会主观的认为设备是不会出问题的、运营商是不可能出问题的、业务程序是不存在问题的……但是，事实上，这些都有可能是导致故障产生的根源所在。我们在分析、定位、解决故障的过程中，一定要在严密推理的情况下大胆假设，站在网络交互的本质层面小心求证。

       我们要明白，在网络的世界里，一切皆有可能发生！

1，该案例为误开启ARP代理功能导致的疑难故障；

2，该故障的触发是由于XP与vista操作系统发送的免费ARP报文格式不一致导致的；

3，关于ARP代理请参考本博客《ARP代理（Proxy ARP）》一文；关于免费ARP，请参考《免费ARP（gratuitousARP）》一文；

4，跟这个案例分析的原因有关的类似故障案例还有netyourlife论坛上的《为什么VISTA不能穿过ASA》，大家可自行查看比较；

5，针对该案例做的相关实验，请大家参考本博客《关于防火墙的arp代理功能对不同格式的arp报文的处理情况的实验》一文；

【我的案例】：

故障环境

1 网络拓扑 

2 说明

1、内部机器全部在同一网段，经过一个二层交换机接入防火墙，通过防火墙的NAT访问互联网；
2、以前内部办公机器都是xp操作系统，现在新采购了一批vista操作系统新机器。

故障现象

1、 vista操作系统的办公机器在接入网络时，本地连接便显示网络连接正在识别，提示找不到网络；
2、 使用ifconfig/all命令查看vista系统的ip地址情况如下图所示： 

       通过上图，我们发现：vista系统的首选地址变成了169.254.180.208，而不是先前收到设置的192.168.0.23了；
3、 用户反馈，如果vista系统的办公机器只接入交换机不会出现这种情况，但一旦接入防火墙，故障现象就会出现。
4、 XP系统的办公机器一切正常。

故障分析

1、 首先根据用户反馈的故障现象，从自己的经验出发，个人认为这个跟网络应该没有什么关系，估计是操作系统的问题，于是打microsoft OEM厂商的800电话咨询关于vista系统ip地址“突变”的原因，得到的回复是：从未出现过此类问题，可能跟现场环境有关。
2、 根据用户反馈的情况测试：首先，设好vista系统机器的ip地址后，将其接入一台普通的交换机，查看vista机器的ip地址，的确正常，如下图所示： 

       难道真的跟防火墙有关？
3、 既然怀疑跟防火墙有关，我们便将注意力放到防火墙上来，telnet到防火墙上，使用使用tcpdump –i eth2 host 192.168.0.23 –n命令抓取测试vista主机的数据包。
4、 重启vista主机，发现vista主机在系统启动后，发送了一个源ip为0.0.0.0、目的ip为其配置的ip的arp请求包，同时，防火墙回应了该arp请求包，如下图所示： 

5、防火墙为什么会回应该数据包？我们检查防火墙配置，发现防火墙上手动将内部办公网段设为静态arp代理。跟用户确认该问题，原来用户误认为该功能可能会解决arp欺骗问题，尝试设置后，忘记将其删除了。

故障解决

       删除防火墙上手动添加的arp代理项，故障现象消失，故障解决。

引申问题

1、通过抓取数据包，我们可以发现vista系统与xp系统在网卡引导阶段发送的“免费”arp报文格式的差别：
VISTA 系统发送的免费ARP请求包格式为：

下图为wireshark抓取的vista系统网卡引导阶段发送的arp数据包格式：                      
 

XP系统中发送的免费ARP请求包格式为：

下图为xp系统发送的免费arp包格式： 

       为什么VISTA系统在网卡地址加载期间发送这种格式的ARP数据包呢？关于这个问题已经有人做过相关的测试，我也验证了这个实验，下面为实验的过程，引用自netexpert的gwdwx：
“A机－B机两台xp对联测试：
1）按照xp的arp包格式（源ip＝目的ip＝a机ip），用sniffer伪造arp包向b机发包，b机不断提示ip冲突；
2）按照vista的arp包格式（源ip＝0.0.0.0），用sniffer伪造arp包向b机发包，b机不提示。
这就是最明显的区别，看来vista比xp还谦虚，它不仅让出ip，而且还不让对方发现有ip冲突，宁可牺牲自己”。

关于这个问题的详细讨论，可以参考如下链接：
http://www.netexpert.cn/viewthread.php?tid=19463&pid=125237&page=1&extra=page%3D1#pid125237

2、细心的兄弟应该会发现这样一个问题：既然是防火墙启用了针对内部办公网段的arp代理功能，使得vista在网卡加载地址期间发生了ip地址冲突，导致了vista系统机器无法访问互联网，那么，为什么xp系统在网卡加载地址期间没有出现地址冲突呢？
       实验证明：防火墙虽然启用了针对办公网段的arp代理功能，但是，防火墙只响应vista系统格式的arp请求报文，而不响应xp系统网卡加载地址时发送的免费arp报文。

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) 浏览(9863)

某单位经过CA认证的业务应用访问缓慢故障分析案例

作者：易隐者 发布于：2012-9-3 9:47 Monday 分类：网络分析

【写在之前】：

1，此案例为业务应用系统客户端程序BUG问题导致的故障；

2，此案例可作为业务系统分析评估的应用场景，为业务系统正式上线前测试阶段通过网络分析技术手段发现业务系统稳定性问题的案例；

3，此案例中涉及到的知识点，请大家参考本博的《TCP重传》一文；

【我的案例】：

故障环境
      故障网络结构如下图所示： 

       该单位的网络划分有办公区域和服务器区域，办公区域的机器经过防火墙的地址转换，访问服务器区域的相关服务器。

业务应用访问的流程

       业务应用是基于B/S架构的，客户端通过IE浏览器对服务器进行访问；进行访问时，在IE浏览器中输入认证服务器的地址，经过CA认证服务器认证成功后，在通过CA认证服务器的代理，访问业务应用服务器。

故障现象

1，客户端在访问应用服务器时，有时页面打开的速度非常的慢，要等好几分钟才能完全打开页面，打开页面后进行站内访问时，速度也很慢；
2，直接将客户端接在服务器区，访问正常；
3，其他的业务应用全部正常；
4，业务系统开发商与网络集成商均否认是自己维护的系统导致故障了出现。

故障分析

1 分析思路

       通过故障现象，我们可以明确这是单一的业务应用故障，问题应该跟该业务的数据交互有关，因此，我们应该将分析的重点放在该业务交互的详细过程。
       另外，由于这个故障并不是一直出现，因此，我们需要在故障出现时，捕获其数据报文的详细交互过程，从而发现故障原因所在。

2 分析过程

1， 在测试主机上开启网络分析工具，并在故障现象出现时，捕获其交互的数据报文。
2，分析故障时数据报文详细的交互过程，如下图所示： 

        通过上图交互过程的分析，我们发现，第一个数据报文是客户端向服务器发送的SYN请求报文，第二个报文是服务器对客户端SYN报文的响应，其SYN标志和ACK标志位都置1了，下面5个报文都是第二个报文的重传。在这里我们没有看到正常的TCP三次握手建立连接的过程，客户端并没有响应来自服务器的SYN报文，服务器因此不断地重传SYN报文，正是这个原因导致了客户端与服务器业务交互异常缓慢。
3，由于该报文是在客户端直接捕获的，因此我们可以确定是客户端未响应服务器的SYN报文，而不是中间设备丢弃了客户端对服务器SYN报文的响应报文。那么为什么客户端不响应服务器的SYN报文呢？
4，将上述分析情况与业务系统开发商沟通之后，开发商才确认是自己的业务客户端出现了问题。 

3 分析结论

       通过上面的分析，可以得出该故障是由客户端本身不响应服务器的SYN报文导致的。

故障解决

       通过我们的分析定位，找到故障的源头是客户端，通过与CA认证程序提供厂商沟通后，发现程序中有一段代码编写存在一些问题，当客户端与服务端的IP地址不在同一网段时，有时会出现客户端不响应服务器SYN报文的情况，在业务开发商优化客户端的程序代码后，该故障得到解决。

阅读全文>>

标签: 疑难故障 TCP TCP重传 SYN 重传 SYN重传 CA BUG

评论(5) 引用(0) 浏览(11464)

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应用启用了应用层检测，如下图所示： 

        至此，我们基本上可以断定是防火墙的FTP应用层检测BUG导致了这个故障的产生。

故障解决

       在防火墙上取消FTP应用绑定，让防火墙不要对FTP的数据包进行深度的过滤和检测，再次登陆FTP服务器，一切正常，至此该疑难故障解决。

阅读全文>>

标签: 疑难故障 tcpdump 应用层检测 报文深度检测 DPI FTP ICMP重定向

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