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

2020/03 17 14:03

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

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

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

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

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

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

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

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

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

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

总结一下,基本的排查原则:首先是定位,分段去查找,找到问题存在的那一段。然后是最小化(这个应该先做的,这次被其他因素影响后做了,不然早就就决问题了),这两步的目的呢,都是把问题减少到最小的范围,然后再去检查。就比较容易了。定位到最小范围后,首先考虑硬件(因为这个容易查),然后呢就是配置部分的问题了。
————————————————
版权声明:本文为CSDN博主「oarsman」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/oarsman/article/details/100574453

1 Comment

  1. #1
    admin

    admin

    2years ago -@

    giao

  2. 发表回复

    欢迎回来 (打开)

    (必填)