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

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

作者：易隐者 发布于：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) 浏览(19173)

IP分片(IP Fragment)

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

为什么要分片

       不同的链路类型能够支持的最大传输单元值（MTU: Maxitum Transmission Unit）主要是由相关RFC文档规定的，常见的以太网链路的MTU值为1500，如果需要转发的IP报文超出其转发接口的MTU值，则在转发该报文之前，需要将其分片，分为多个适合于该链路类型传输的报文，这些分片报文在到达接收方的时候，由接收方完成重组。

       各种常见链路类型的MTU值如下图所示： 

报文的分片和重组

       我们先来看一下分片的过程，为了简单起见，我就用《TCPIP详解卷一》第11章《UDP：用户数据报协议》中关于IP分片的案例，应用进程将1473字节应用字段交给UDP处理，UDP加上8字节的UDP报头之后，交给IP层处理，IP层在转发之前，发现该报文长度超出转发接口的MTU，因此需要分片，分为两个IP分组，如下图所示： 

       从上图可以看出原始的IP报文经过分片后，只有第一个分片报文是带有四层信息的，后续报文均不带四层信息，为做直观展示，我找了一个实际环境下抓取的分片报文，如下图所示： 

       这是分片的第一个报文，我们可以看到该报文IP层封装的上层协议为ICMP协议，这是一个ping报文（上层协议信息），我们再来看一下后续分片报文的解码：

       这是分片后续报文，我们能看到封装的是ICMP协议，但是封装的上层协议的具体信息就无法看到了。

       IP数据报被分片之后，所有分片报文的IP报头中的源IP、目的IP、IP标识、上层协议等信息都是一样的（TTL不一定是一样的，因为不同的分片报文可能会经过不同的路由路径达到目的端），不同的地方在于分片标志位和分片偏移量，而接收方正是根据接收到的分片报文的源IP、目的IP、 IP标识、分片标志位、分片偏移量来对接收到的分片报文进行重组。

       接收方根据报文的源IP、目的IP、IP标识将接收到的分片报文归为不同原始IP数据报的分片分组；分片标志中的MF位（More Fragment）标识了是否是最后一个分片报文，如果是最后一个分片报文，则根据分片偏移量计算出各个分片报文在原始IP数据报中的位置，重组为分片前的原始IP报文。如果不是最后一个分片报文，则等待最后一个分片报文达到后完成重组。

分片带来的问题

1， 分片带来的性能消耗

       分片和重组会消耗发送方、接收方一定的CPU等资源，如果存在大量的分片报文的话，可能会造成较为严重的资源消耗；
       分片对接收方内存资源的消耗较多，因为接收方要为接收到的每个分片报文分配内存空间，以便于最后一个分片报文到达后完成重组。

2，分片丢包导致的重传问题

       如果某个分片报文在网络传输过程中丢失，那么接收方将无法完成重组，如果应用进程要求重传的话，发送方必须重传所有分片报文而不是仅重传被丢弃的那个分片报文，这种效率低下的重传行为会给端系统和网络资源带来额外的消耗。

3， 分片攻击

       黑客构造的分片报文，但是不向接收方发送最后一个分片报文，导致接收方要为所有的分片报文分配内存空间，可由于最后一个分片报文永远不会达到，接收方的内存得不到及时的释放（接收方会启动一个分片重组的定时器，在一定时间内如果无法完成重组，将向发送方发送ICMP重组超时差错报文，请大家参考本博客《ICMP重组超时》一文），只要这种攻击的分片报文发送的足够多、足够快，很容易占满接收方内存，让接收方无内存资源处理正常的业务，从而达到DOS的攻击效果。

4， 安全隐患

       由于分片只有第一个分片报文具有四层信息而其他分片没有，这给路由器、防火墙等中间设备在做访问控制策略匹配的时候带来了麻烦。
       如果路由器、防火墙等中间设备不对分片报文进行安全策略的匹配检测而直接放行IP分片报文，则有可能给接收方带来安全隐患和威胁，因为黑客可以利用这个特性，绕过路由器、防火墙的安全策略检查对接收方实施攻击；
       如果路由器、防火墙等中间设备对这些分片报文进行重组后在匹配其安全策略，那么又会对这些中间设备的资源带来极大的消耗，特别是在遇到分片攻击的时候，这些中间设备会在第一时间内消耗完其所有内存资源，从而导致全网中断的严重后果。

       基于以上原因，很多应用程序都尽量避免分片的产生，其通过将IP报文的分片标志中的DF位（Don’t Fragment）置一来实现，而这可能给应用带来一些难以预料的麻烦。下一篇我将介绍端系统如何处理这种状况，请大家关注。

分片补充

1，分片既有可能发生在端系统（发送主机）上，也可能发生在转发报文的路由器、防火墙等中间系统上。
2，分片只发生在转发出接口上。

跟分片有关的案例

        后续我会在本博客里添加一些跟分片有关的案例，有兴趣的同学可关注。

阅读全文>>

标签: ip分片 重组超时 IP标识 icmp差错 分片 ip fragment IPID UDP 分片攻击 分片偏移量 DF位 MF位 MTU 重组 fragment ICMP

评论(6) 引用(0) 浏览(94527)

视频点播服务间歇性中断故障分析案例

作者：易隐者 发布于：2012-8-1 22:15 Wednesday 分类：网络分析

故障环境

1 网络拓扑

2 说明

1、VOD在线视频是通过web页面观看的，通讯流全部使用HTTP的80端口传输数据；
2、客户端与服务器是纯路由环境下完成数据交互的。

故障现象

1、客户端通过浏览器在线观看VOD视频时，不定时（有时几分钟、有时十几分钟，没有规律）的出现中断情况；
2、使用ping命令长时间测试VOD服务器的连通性，一直正常；
3、异常时，VOD服务器的web页面访问正常。

阅读全文>>

标签: IP标识 sack tcpdump 重传 IPS 策略误报 视频点播故障 IPID

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

疑难网络故障的分析方法和原理之关联分析法

作者：易隐者 发布于：2012-7-4 12:51 Wednesday 分类：网络分析

      前面我们在讲解对比分析法时，大家可能会有这样的疑问：对比分析法主要是通过对进出中间设备的数据包做对比分析，从而得出相关结论的，但是，我们都知道，很多中间设备会对经过它的数据包做一些修改和处理，那么我们怎么能够将进入设备前的数据包与被中间设备修改后转发出来的数据包对应起来呢？接下来这一节就是专门讲解我们如何将这些数据包关联起来的方法―—关联分析法。

关联分析法
       数据包在经过各种中间设备时，经常会出现被中间设备（例如存储转发设备、NAT设备、负载均衡设备等）更改的情况，这对于我们分析问题非常不利，我们在做对比分析时，必须要将相应的数据流、数据包关联对应起来，否则就失去了可比性。

阅读全文>>

标签: IP标识 关联分析法 五元组 应用字段

评论(2) 引用(0) 浏览(15696)