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

【转】VPN Tunnel 口MTU问题解决

作者：易隐者 发布于：2012-12-24 14:00 Monday 分类：案例讨论

【说在之前】：

1，这个帖子是我在锐捷的论坛里看到的，现象很特别，值得研究讨论一番；

2，原帖中仅对故障做了描述，并未给出导致故障产生的根本原因，大家可以自行先考虑考虑，并尝试分析推测一下可能的原因，可在此贴下留言以供探讨；

3，此案例的正确答案应该已由回复中的liuquyong兄弟给出，主要原因在于加解密次数的减少导致了ERP交互性能的提升。关键就在于下面这张来自于思科的加解密流程图：

【原文连接】：

  http://support.ruijie.com.cn/showtopic-22758.aspx

【原文全文】：

Gre隧道，Tunnel接口的MTU值设置为大于1500的值，有效吗？带着这个问题我讲讲今天遇到的问题：
NPE20（总部，版本RGNOS 9.12）与NBR300（分部,版本RGNOS 9.12）建立Tunnel 0接口的GRE隧道。
2010年初的时候刚开始用Tunnel功能，当时show interface tunnel 0  显示的 Tunnel 的 MTU值 1464，此时分部访问总部的ERP（用友U890，C/S架构，通过Tunnel隧道来访问的）很慢，卡！只要一遇到分部客户端与服务器之间有数据交互的时候，就异常的卡，有时软件直接无响应。
命令行将此Tunnel的MTU值设置为65535，此时访问速度“嗖”的立刻上去，只能用两个字形容：流畅！
前天，我将NPE20和NBR300都升级到最新的9.17 2P1 B4版本，9.17的Web控制界面操控性以及网速都有一定的提升，但这时出现问题，Tunnel的MTU值设置为65535之后，会自动变回1464，企业内的应用再度变卡，就和上述曾经遇到的卡的情况一样。并且无论如何都不像9.12版本那样保持65535。
此问题一直延续到今天。于是迫于无奈，在咨询了锐捷400电话客服之后，由3034号客服帮我将NPE20、NBR300都刷回9.12版本。刷回9.12版本之后的tunnel 0 先是保持1464默认值，这时还是卡，没有任何起色。手动将MTU值设置为65535，分部访问总部的ERP访问速度和响应速度一下子就上去了，非常流畅！
在咨询3034客服之前，我也咨询过几个客服关于MTU值的问题，得到的答案基本上都是类似于“公网传输数据包的MTU 最大只能1500" 、  “你设置为65535实际上没有效果”之类的话。并且让我两端互ping来测试是否丢包，互ping的时候的确是不丢包的，就算互ping的时候的指定ping包的大小也基本不丢包。
但是我想说，这只是理论，而我所遇到的问题是事实，事实胜于雄辩，Tunnel 0 的MTU为1464时与65535时相比，企业分部与总部之间的内部应用访问速度效果提升是：绝对异常明显的！！
所以，在这里我第一想说感谢3034客服帮我恢复到9.12，这个可以保存手动设置的65535MTU值的版本。第二我想恳请锐捷能够在下一个RGNOS版本中将GRE隧道的Tunnel 接口的这个MTU值改为可以保存用户手动配置的值，比如手动设置为65535，而别再自动恢复理论默认的1464之类的值。
因为今天我遇到的问题的确是：相对与MTU1464的默认值，MTU 65535时的隧道内访问速度是：提升绝对异常明显的！所有的事实，3034号客服可以证明！问题虽解决了，但是他也比较纳闷比较难解释。
我其实很纠结，我想用9.17 2P1 B4的新特性，包括上外网的网速也有一定的提升，但是无奈只能用9.12这个老版本。

阅读全文>>

标签: 丢包 故障 交互 MTU ping tunnel接口 GRE 锐捷

评论(19) 引用(0) 浏览(38780)

更换设备后业务访问故障案例

作者：易隐者 发布于：2012-12-5 19:18 Wednesday 分类：网络分析

故障环境

网络拓扑

       故障环境下的拓扑结构如下图所示： 

1，分公司与中转区域通过互联网建立VPN隧道；
2，中转区域通过专线与总部业务服务器区域互联；

业务访问流程

       中转区域机器通过专线直接访问总部业务服务区域的服务器，而分公司则先通过互联网与中转区域建立VPN隧道，经中转区域CISCO VPN设备后，再访问总部业务服务区域的服务器。

故障现象

       此次故障现象主要表现为：
1，分公司只有极少数机器可以正常访问总部的业务服务器，绝大部分机器都不能访问总部的服务器；
2，中转区域全部无法正常访问总部业务服务器；
3，出现上述故障现象时，使用ping命令做连通性测试，都是正常的，无较大延时也无丢包现象；
4，上述现象发生在中转区域更换新的CISCO VPN设备之后，使用以前老的CISCO VPN设备未出现任何问题；
5，新的CISCO VPN设备的配置是从老设备上的配置导入的，因此可以肯定配置完全一致。

故障分析

1 分析过程

       根据故障现象以及前期的测试情况来看，该故障属于业务应用故障，我们认为站在数据报文交互的角度进行分析比单纯猜测和毫无根据的做各种测试更有效率。

 故障重现
       我们首先选择一台IP地址为10.18.3.22的机器作为测试机，并在测试机器上使用IE浏览器访问10.3.3.21服务器，以便在故障现象出现时，我们捕获测试机与服务器业务交互的报文。

近故障点抓包，分析交互过程
       考虑到服务器端在总部，在服务器近端抓包难度很大，我们决定先在客户端近端抓包。
在测试机访问服务器故障重现时，我们在测试机近端捕获了测试机与服务器间的业务交互报文，如下图所示：  

测试机与服务器的交互报文
 
对应的TCP数据流图

       通过对这个报文交互过程的分析，我们发现，测试机与服务器的TCP三次握手建立连接正常，客户端向服务器发送“GET”请求也正常，问题出现在服务器给测试机的响应报文，我们在测试机近端抓包，只看到了服务器向客户端发送的28字节的报文，而我们通过该TCP报文的Seq=1433可以计算出，在这个报文之前，还有一个载荷长度为Len=1433-28-1=1404字节的TCP报文未正常到达测试机。测试机在等待45秒后，由于一直未收到该报文，其主动向服务器发送FIN报文，正常释放了这个TCP连接。
       纵观整个过程，我们可以自然的得出结论：服务器端的报文在网络中被中间设备丢弃，导致了故障的产生。
一般而言，偶尔丢包是正常的，TCP会通过重传机制，保证应用正常交互，但是在这个故障交互的报文中，我们仅看到有报文被丢弃，并且这个报文在45秒的时间内，一直未到达测试机，这不符合TCP重传的工作机制，只有一种情况可以解释这种现象，那就是这个一直未到达测试机的报文，其原始报文和重传报文都被中间设备丢弃了。
       结合故障现象是在更换为新的CISCO VPN设备后出现的，我们很自然的想到，应该是新更换的CISCO VPN设备丢弃这个报文。那么CISCO VPN设备并未做特殊的设置，一般不会丢弃特定报文，联想到这个被丢弃的报文应用字段长度为1404字节，加上20字节的TCP报头和20字节的IP报头，其IP报文长度应该有1444字节，是否有可能是其超出了CISCO VPN设备的某些接口的MTU呢？
       对CISCO VPN设备的特性并不了解，那么我们还是做一个简单的测试，验证我们的分析和推论是否正确。

验证
       将测试机网卡的MTU值修改为1400之后，再次尝试通过IE访问总部的服务器，访问完全正常，下面为修改MTU值之后的测试机与总部服务器之间正常交互的报文： 

       上述正常交互的报文，充分验证了我们前面的推论。

2 分析结论

       老CISCO VPN设备的tunnel接口MTU等属性并没有保存在配置文件里，因此虽然将老设备的配置直接导入到新设备中，但是新更换的CISCO VPN设备VPN tunnel接口MTU较小，导致服务器发给客户端的TCP大包报文被丢弃，引发业务访问故障的产生。
       而分公司极少数机器在更好新设备后仍然能够正常访问服务器，是因为这些机器本身网卡的MTU值较小，因此虽然新的设备上线，但并不影响这些机器对服务器的正常访问。

故障解决

      调整CISCO VPN设备相关tunnel口MTU值，此故障解决。

阅读全文>>

标签: 疑难故障 丢包 MTU VPN

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

数据包中出现超长帧的分析

作者：易隐者 发布于：2012-11-1 16:36 Thursday 分类：网络分析

抓包环境

       在用户处的抓包环境如下图所示： 

说明：
1、在核心交换机上做端口镜像抓取进出互联网的数据包；
2、监听端口为一台服务器接入端口，在服务器上开启科来网络分析系统抓取数据包。

问题现象描述

       在抓取数据包，并对数据包进行分析时，我们发现了一些问题，主要是以下几点：
1、 数据包中有很多长度超过1518字节的数据帧，其字节分布从1600-8880字节不等。如下图所示： 

这是正常的吗？是什么原因导致的呢？
2、 存在较多的IP标识一致但是长度大小不一致的数据包，如下图所示： 

问题分析

1 关于超长帧问题的分析

1、一般以太网环境中数据链路层能够传输的最大数据为1518字节，有些网卡在故障时会发送一些超长帧，但是这种帧一般都会被中间设备或捕获数据包的网卡丢弃，抓包工具一般无法正常显示，但是，在此次所捕获的数据包中，这些超长帧都能正常显示，而且通过分析其数据包通讯过程，也能够确定其通讯正常。可以排除设备网卡故障的可能。
2、在网上查找了一些关于超长帧的文档，发现其是一种专门为千兆以太网而设计的厂商标准的超长帧格式，其长度从9000字节～64000字节不等。采用Jumbo Frame能够令千兆以太网性能充分发挥，使数据传输效率提高50%～100%，超长帧一般在内部网络的存储环境中应用较多。Jumbo Frame需要在相互通讯的2个通讯端口(交换机端口或网卡端口)上同时支持，而且与以前的以太网产品不兼容，因此主要会应用于千兆主干的端口之间以及服务器端口接入到网络主干的链路。交换机把Jumbo Frame格式的数据转发向不兼容Jumbo Frame的端口时应进行帧格式的转换，即把Jumbo Frame帧格式的数据转换成标准以太网的帧格式，从而保证其正常工作。相反，从不兼容Jumbo Frame的端口向支持Jumbo Frame的端口转发数据时，交换机可以把多个标准以太网帧合并成超长Jumbo Frame帧，从而提高传输效率。
3、通过对数据包的分析，结合相关的资料，我们基本上可以推断出网络中的相关服务器和交换机支持jumbo frame，并且服务器正在使用超长帧与交换机进行相应的数据交互。
4、验证：可以在相应的服务器与交换机上查看它们对超长帧支持的相关设置。

2 关于IP标识一样但数据包大小不一样问题的分析

1、我们知道IP标识一样，说明属于同一数据包，如果在网络中同一数据包出现多次的话，说明网络中存在IP分片或网络中存在环路，但是，我们在数据包中未发现IP分片数据包，并且，如果是环路的话，其TTL值肯定会逐渐减小至0，但通过对数据包的分析，也未发现其TTL为1或0的数据包，因此可以排除网络环路或IP分片的问题。
2、我们在仔细对比分析了相应的数据包后，发现IP标识一样的数据包除了长度大小不一样外，还存在以下几点异同：
（1） 源MAC地址不一样；
（2） TTL值不一样；
（3） TCP序列号一致。
具体如下图所示：
第三个PACKET的数据包解码图：
 

TTL值由128变成127了，说明经过了一跳路由，MAC地址变了就是经过路由的证据，为什么会经过一跳路由呢？联系我们的抓包拓扑和环境，我们便能明白：
科来网络分析系统是部署在服务器172.16.4.55上的，服务器与其他主机间的通讯数据流首先会被科来网络分析系统捕获下来，同时，服务器的网卡又捕获进出互联网出口的数据流，因为核心交换机上做了针对互联网出口的端口镜像，并且监听口为服务器在交换机上的接入端口。具体数据流见下图的图示： 

也就是说，第三个packet是服务器网卡发送的数据包，而第四个packet是核心交换机互联网出口转发的数据包，它们是同一数据包，经过核心交换机的VLAN间路由后，TTL值减1了，并且，将服务器的源MAC替换成核心交换机相应VLAN的MAC。
3、上面我们分析了第三个packet与第四个packet属于同一数据包，那么，为什么它们的长度大小不一样呢？考虑到“交换机把Jumbo Frame格式的数据转发向不兼容Jumbo Frame的端口时应进行帧格式的转换，即把Jumbo Frame帧格式的数据转换成标准以太网的帧格式，从而保证其正常工作。”，我们可以推断第四个packet是核心交换机将第三个packet转换而来的。
4、验证：我们可以通过计算上下packet的TCP segment段长来验证是否是核心交换机将服务器发送的超长帧转换成多个较小的packet进行传输。如下图所示： 

我们可以发现第三个packet的TCP段长正好是第四个packet与第五个packet的TCP段长之和。同样的道理，我们可以一一验证后续的超长帧与相关数据包的这种关系。

结论

通过上面的分析，我们得出以下结论：
1、网络中出现超出以太网MTU值的数据包是由于jumbo frame造成的，Jumbo frame在内部的服务器之间或服务器与交换机之间经常使用，以提高数据传输的效率，在互联网上不会出现。
2、jumbo frame的使用需要相关服务器和交换机的支持。
3、出现的IP标识一致的数据包是由于同一数据包被捕获了两次，长度大小不一样是由于后面的长度较小的数据包是交换机将前面较大的数据包转换为多个常规以太网数据包而来。

引申问题

假设服务器在很短的时间内发送了大量的超长数据包，其IP标识都很接近，在经过交换机时，交换机需要对这些超长的数据包进行转换，一个超长的数据包会被转换成多个常规的数据包，交换机在进行这个转换的时候，需要给那些转换后常规数据包重新分配IP标识（转换后的第一个数据包的IP标识为转换前的超长数据包的IP标识，后续的数据包的IP标识逐一增加），那么，是否会存在转换后数据包的IP标识与转换前的数据包的IP标识一样而导致对端设备接收异常呢？如下图所示： 

我们以第9个packet至第15个packet等7个数据包来分析这个问题，如下图所示：

 第9个packet、第10个packet都是超长帧，经过交换机是需要转换的，通过相应的IP标识值以及TCP段长的计算，我们可以知道第9个packet被转换为第11、12两个packets，第10个packet被转换为第13、14、15三个packets。
       通过比较这些数据包的IP标识，我们可以发现服务器在发生这些超长数据包时，似乎已经考虑到我们前面提到的问题，并将其相应的IP标识设置为转换后不会存在冲突的值。

阅读全文>>

标签: IP标识 IPID TTL MTU 超长帧 Jumbo Frame

评论(1) 引用(0) 浏览(13170)

TCP MSS与PMTUD

作者：易隐者 发布于：2012-9-6 19:16 Thursday 分类：网络分析

 

       一旦DF位置一，将不允许中间设备对该报文进行分片，那么在遇到IP报文长度超过中间设备转发接口的MTU值时，该IP报文将会被中间设备丢弃。在丢弃之后，中间设备会向发送方发送ICMP差错报文。
为了简单直观的展示这个交互的过程，我做了下面这个图示： 

       我找了一个实际环境下捕获的ICMP需要分片但DF位置一的差错报文，下图为其解码格式： 

       我们可以看到其差错类型为3，代码为4，并且告知了下一跳的MTU值为1478。在ICMP差错报文里封装导致此差错的原始IP报文的报头（包含IP报头和四层报头）。

       一旦出现这种因DF位置一而引起丢包，如果客户端无法正常处理的话，将会导致业务应用出现异常，外在表现为页面无法打开、页面打开不全、某些大文件无法传输等等，这将严重影响业务的正常运行。
那么客户端如何处理这种状况呢？
TCP主要通过两种方式来应对：
1， 协商MSS，在交互之前避免分片的产生
2， 路径MTU发现（PMTUD）

TCP MSS

       TCP在三次握手建立连接过程中，会在SYN报文中使用MSS（Maximum Segment Size）选项功能，协商交互双方能够接收的最大段长MSS值。
       MSS是传输层TCP协议范畴内的概念，顾名思义，其标识TCP能够承载的最大的应用数据段长度，因此，MSS=MTU-20字节TCP报头-20字节IP报头，那么在以太网环境下，MSS值一般就是1500-20-20=1460字节。
客户端与服务器端分别根据自己发包接口的MTU值计算出相应MSS值，并通过SYN报文告知对方，我们还是通过一个实际环境中捕获的数据报文来看一下MSS协商的过程：

       这是整个报文交互过程的截图，我们再来看一下客户端的报文详细解码： 

       上图为客户端的SYN报文，在其TCP选项字段，我们可以看到其通告的MSS值为1460；我们在看看服务器端的SYN/ACK报文解码： 

       上图为服务器端给客户端回应的SYN/ACK报文，查看其TCP选项字段，我们可以发现其通告的MSS值为1440。

       交互双方会以双方通告的MSS值中取最小值作为发送报文的最大段长。在此TCP连接后续的交互过程中，我们可以清楚的看到服务器端向客户端发送的报文中，TCP的最大段长度都是1440字节，如下图解码所示：

       通过在TCP连接之初，协商MSS值巧妙的解决了避免端系统分片的问题，但是在复杂的实际网络环境下，影响到IP报文分片的并不仅仅是发送方和接收方，还有路由器、防火墙等中间系统，假设在下图的网络环境下： 

       中间路径上的MTU问题，端系统并不知道，因此需要一个告知的机制，这个机制就是路径MTU发现（PMTUD： Path MTU Discovery ）！

PMTUD

       说起PMTUD，我们必须在此回到上面讲到的ICMP需要分片但DF位置一差错报文，还记得那个ICMP差错报文中有一个字段是告知下一跳的MTU值的吗？PMTUD正是利用ICMP需要分片但DF位置一差错报文的这一特性来实现的。
       发送方在接收到该差错报文后，会根据该报文给出的下一跳的MTU值计算适合传输的最大段长度，从而在后续的发送报文过程中，避免在中间路径被分片的情况产生。
       这在端系统主要是通过在路由表里临时添加目的主机路由并将ICMP差错报文告知的下一跳MTU值跟该主机路由关联起来来实现。
       PMTUD的确是个非常不错的机制，但是在复杂的实际网络环境中，有时候会失效，因为为了安全起见，有些网络管理员会在路由器、防火墙等中间设备上设置过滤ICMP报文的安全策略，这将导致ICMP差错报文被这些中间设备丢弃，无法达到发送方，从而引起PMTUD的失效，网上有个宫一鸣前辈共享的案例——《错误的网络访问控制策略导致PMTUD 实现故障一例》，该案例正是说明这种情况绝好的例子，大家可以自行百度此文档学习参考。

       值得一提的是PMTUD仅TCP支持，UDP并不支持PMTUD。

       由于PMTUD可能存在ICMP差错报文被过滤的情况，很多中间设备的接口支持adjust tcp mss设置功能，思科路由器一般是在接口模式下使用命令“ip tcp adjust-mss 1400 ”来做设置，其他的品牌产品的相关设置大家可在实际工作环境下自查相关品牌和产品的使用手册。

        这个功能主要是通过由中间设备修改经过其转发的TCP SYN报文中的MSS值，让中间设备参与进TCP 三次握手时SYN报文的MSS协商来避免分片。

       需要注意的是，该功能不像MTU值，只针对出接口，此功能一旦开启，其将针对该接口的收发双向有效。
我做一个简化环境下的工作过程图示以便于大家理解其工作过程：

阅读全文>>

标签: TCP icmp差错 分片 SYN TCP选项 UDP MTU ICMP PMTUD MSS

评论(4) 引用(0) 浏览(27894)

【转】负载均衡故障诊断：一个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) 浏览(9878)

1 2