一次网络丢包问题排查的经历

前两天，有一个同事跑来找我帮忙。说他们项目现场出现了一个奇怪的事情。在做性能测试的时候，发现偶尔会出现消息延迟增大的问题，有时候一条消息发出去，需要5秒钟才能够被对方收到。如此长的延迟已经严重影响了性能测试的结果。由于负责现场测试的同事对网络不是十分的熟悉，所以想让我帮忙排查一下。事情紧急，二话不说，动手。

首先看了一下他们的日志，发现并不是所有的消息延迟都很大，只有一小部分会出现这种情况。而且出现延迟的消息从业务功能上来讲没有什么关联性。再加上他们之前在实验室进行性能测试的时候，并没有出现这种问题。因此排除了是软件的原因。那么终点需要怀疑的就是网络的问题了。

于是，第一感觉，可能有网络丢包，于是ping了一下对方服务器，果然，在长ping之下，有大约30%的包丢失了。那么问题的解决就有了方向。下一步就是看为什么会出现丢包了。

紧接着按照原则分段定位。现场的网络结构大致是这样的，我方服务器->我方交换机->客户交换机->客户服务器。 于是，分段ping一下，发现从我方服务器到对端服务器丢包，从我方服务器到我方交换机不丢包。 从我方交换机到对端服务器也不丢包。 这下基本可以确定问题出现在我方服务器到我方交换机这一段了。 丢包的原因有很多，有简单的又复杂的。 自然先从简单的开始排查了。 先排除硬件问题。 换端口，换交换机，换网线，换网卡，换换换换能换的统统换了一遍。结果呢，问题依旧。那么久排除了硬件问题了。

下一步考虑网络配置的问题，由于现场采用了两台交换机堆叠成一台交换机的技术，以前堆叠交换机都是专门的三方网络工程师配置的，而这次是自己人配置的，这位同事是新学的网络配置，新手按照手册配置的。 因此怀疑这里可能有问题。于是关闭了堆叠交换机中的一台，问题依旧。 

原本想按照最小化原则，把交换机上的其他东西都拔掉，但是考虑到现场还有其他系统再测试，再加上主要怀疑对象是在交换机配置上，所以就没有动手拔线。

这个时候想到了检测一下服务器的路由信息是不是有问题，于是用traceroute 命令探测了一下到对端服务器的地址。多次运行后发现，tranceroute居然给出了2中不同的路由。 第一跳有时候是网关，有时候不是网关而是一个未知的 * * *.  这就怪了，网关有问题？

ping了一下网关，发现到网关却没有丢包。由于网关是配置在交换机上的，所以还是怀疑交换机的配置有问题。于是想看一下网关的MAC地址，看看网关是怎么配置的。于是在服务器上用arp 命令查看了网关，我晕，这一看不要紧，发现网关的MAC地址居然在不断的变化，一会儿是交换机管理地址的MAC一会儿是另外一个MAC.  同一个IP MAC居然会变，难道是ARP攻击？ 可这是客户内网啊，而且是新建系统，arp共计的可能性不大。 那么最大的可能就是 IP地址冲突！！！

我们的设备都是我们自己配置的IP自然不可能是我们自己导致的。于是又回到了先前的路上，最小化原则。 通知了其他测试系统暂停一下。 先拔掉了和客户交换机连接的网线，问题依旧。然后拔掉了和下面一个设备厂商的子网对接的网线，果然，问题消失了。 然后呢？然后再插上，问题又出现了。 就是他们呀，总算是逮到他们了。于是赶紧找他们的负责人一问，无语呀无语，他们为了自己方便，没有按照我们的网络规划，自己在下面接了一个路由器，还配了一个和网关一模一样的地址。于是乎，麻烦就出现了。

其实本次解决问题没有什么特别的技术含量。只是网络丢包这种常见的问题，真的要算起来，原因太多，查起来比较麻烦。所以把这次的排查过程记录一下，留个纪念，也给需要的人一点参考。

总结一下，基本的排查原则：首先是定位，分段去查找，找到问题存在的那一段。然后是最小化(这个应该先做的，这次被其他因素影响后做了，不然早就就决问题了)，这两步的目的呢，都是把问题减少到最小的范围，然后再去检查。就比较容易了。定位到最小范围后，首先考虑硬件(因为这个容易查)，然后呢就是配置部分的问题了。