大包传输丢包故障

2012-04-28 · 网络分析 · 网络分析 · 28738 次阅读

故障环境

某公司与集团城域网的连接拓扑大体如下图所示：

说明：

1、办公机器都属于10.12.128.0/24网段；

2、办公机器通过一个二层的 接入交换机、光电转换器接入集团核心交换机。

故障现象

1、网络中办公机器传输大包时有丢包，主要通过在测试机器10.12.128.66上使用如下命令进行测试：ping 10.1.10.9 –l 10000 –t ，即向集团DNS服务器10.1.10.9发送长度为10000字节的数据包，我们发现丢包现象非常严重；

2、网络中小包传输都正常，没有丢包；

3、前期已经使用单机ping大包测试过，没有发现丢包问题。

故障分析

首先通过故障现象的收集和测试验证，我们可以确认该故障属于较为高级的网络故障，难以通过一些基本的测试或策略的检查来定位故障，我们需要进行一些深度的分析。针对此类的丢包故障，我们需要做的就是定位出丢包的位置。

具体故障分析过程如下

1 选取抓包故障点

在实际的网络环境中，我们需要选取相应的故障点进行抓包，考虑到抓包的方便性和相应中间设备的功能特性，我们分别选取多经公司接入交换机的上联接口和核心交换机6509的相应接口作为抓包的故障点。如下图所示：

2 重现故障现象

我们在测试机器10.12.128.66上使用如下命令测试网络的大包传输情况：ping 10.1.10.9 -l 10000 –t ，根据数据包长度和以太网MTU值的计算，我们可以知道该命令将会使测试机器向DNS服务器发送一个1500字节的icmp请求分组、五个1500字节的ip分片分组以及一个1148字节的ip分片分组。

通过该测试命令重现了故障现象：大文件传输丢包情况较为严重。

3 捕获数据包

我们分别在核心交换机6509、多经公司接入交换机上做端口镜像（端口镜像的详细命令和过程在此不再描述），将其相应链路的数据包镜像到我们选取的监听口，我们再通过科来网络分析系统捕获相应的数据包。

4 对比分析

1、首先分析在核心交换机6509上抓取的来自多经公司测试机器的相关数据包（主要为测试机器10.12.128.66向DNS服务器10.1.10.9的icmp请求包、服务器的icmp回应包以及相应的分片包）。

我们发现10.12.128.66的机器向DNS服务器发送了一个1500字节的icmp请求分组、四个1500字节的ip分片分组以及一个1148字节的ip分片分组。具体如下图所示：

这个结果跟我先前计算的结果相比，少了一个ip分片数据包，我们再看紧接着的第七个数据包，如下图所示：

这是DNS服务器10.1.10.9给测试机器10.12.128.66回的一个icmp数据包，我们通过科来网络分析系统的“数据包”视图，对其进行深度分析，具体如下图所示：

通过上面的数据包解码，我们发现这是DNS服务器给测试机器发送的一个icmp重组超时差错报文。结合上面的分析，我们可以推论出：由于测试机器ping DNS服务器的其中一个ip分片包在中间丢弃了，导致DNS服务器在重组测试机器的icmp报文时超时，因此DNS服务器向测试机器发送一个icmp重组超时差错报文，而在在测试机器上则表现为ping丢包。

那么，那个未捕获到的ip分片包到底是在什么位置被丢弃的呢？我们接着往下看。

2、我们接下来分析在多经公司接入交换机上联接口跟故障测试相关的数据包。

通过查看科来网络分析系统的“数据包”视图，如下所示：

我们发现，在多经公司接入交换机的上联接口上，测试机器10.12.128.66向DNS发送了一个1500字节的icmp请求分组、五个1500字节的ip分片分组以及一个1148字节的ip分片分组。

同时，我们也发现了来自DNS服务器的icmp重组超时差错报文，如下图所示：

这说明在数据传输的过程中还是有数据包被丢弃了，结合前面的分析，我们肯定多经公司的接入交换机没有丢弃任何的数据包。

分析结论

通过上面的对比分析，我们可以发现多经公司的接入交换机没有丢弃数据包，核心6509交换机上发现存在被丢弃的数据包，结合我们前面的故障点，我们可以得出以下分析结论：在网络流量较大时，中间光电转换器会丢弃部分大数据包。

故障解决

根据我们前面分析的结果，更换多经公司的光电转换器后，在实际网络环境下，测试大包传输，一切正常。至此，此故障彻底解决。