远程资源访问故障，ping大量丢包故障解决过程_ping包超过15000丢包严重

文档里有截图，若看不清，请把浏览器显示模式放大到200%来观看。 

  一天，有同事反映，他的内网服务器192.168.193.254访问北京总部的资源172.16.1.1无法正常访问，ping测试发现丢包严重，有很多发包request没有得到响应reply，怀疑丢在环境里，让给排查一下。ping测试在服务器上用tcpdump看如下图：

可以看到很多发出的request没有回包，中间部分有回包。没有回包的，他认为这些没响应的ping请求包丢在公司路径里了，导致总部没有回包。

和他确定组网如下：

ros路由器通过vpn连接北京的资源172.16.1.1。

处理思路：

      发包丢包常见原因：

    一个计算机网络模型不外乎，终端设备，节点设备，传输链路，目的设备。可能有发的不对，回的不对，或者路径节点和通信链路的原因。

1、传输质量不好，或者拥塞，经过节点设备收到大量转发的包，而超出转发端口的最大速率，导致丢弃一部分包。

2、环境中存在节点ip冲突或者mac冲突，导致一部分发包发给错误mac，导致正常路径没有收到包。

 3、和第二种情况类似，有的设备有多个网卡，配置有不同的ip地址，当接在同一交换机下，会出现响应目的ip是另一个网卡ip的arp请求的情况，导致ping的request发给另一个mac地址，而这个网卡不是自己所属ip，可能不回ping的reply消息，造成源设备打印time out。

4、自身或者经过节点设备路由配置错误，导致发给另一个节点ip而这个节点没有转发功能，ping的request被终止在设备里，而导致丢包。                                

ping丢包，可以由上逐个节点跟踪抓包，和源设备抓包比对，利用ping的发出request的序号来判断丢了那些包？第3种很少见，我们就判断是否属于上面124三种情况中的一种，丢在那个范围节点了。

看组网，自己pc去ping172.16.1.1，看到很少有丢包，如下图：

排除原因1的可能性，判断一下是否是2,4的原因？ 

很奇怪，为啥他的ping丢包这么厉害，决定从上到下ros到核心交换机逐级抓包，看看丢在哪一级了？

 在出口ros上抓包，看到ping的包序号不连续，上来的ping的request消息均收到了目的方回复的reply消息，判断是很多ping的request消息没有发到ros导致，没有丢在ros路由器侧。服务器侧看到发出的ping的seq连续，而ros出口看到只有很少一部分，序号也不连续。

如上图：

但同事的抓包文件里显示发出ping的序号是连续的

决定镜像抓一下机柜汇聚交换机到核心交换机间的包看看，发出来的是否有问题？

发现序号不连续，过来的ping的request均收到回包。判断测试交换机发出的ping消息的request消息已经丢了好多。排除原因2，查看服务器的配置，看是否是原因4？

觉得交换机丢包的可能性不大，到服务器上192.168.192.254上去看看？

看ip配置

执行route   -n查看路由表的情况？

看到如上图中有两个0.0.0.0的路由表项，配置有两个默认路由，而且metric等级一样！

决定执行tcpdump  -i any   -nne   icmp 看看发出的mac地址，另起一个putty进行ping看看。

发现有一部分ping request发向了另一mac地址，这些request都没有返回ping的reply消息。

发现发给fa:16:3e:1c:fd:81的ping的request消息都没有收到reply消息。

而发给c8:50:e9:67:fa:0c却收到的reply消息，检查一下这两个mac对应的ip地址。

检查这两个mac地址：

由mac地址表对应关系看出，双路由导致发给192.168.193.116的mac地址的包没有收到响应reply消息。

同事反馈，116那条路由是过去测试虚拟机临时加的，不能上外网，现在不使用。所以删掉路由route del -net 0.0.0.0/0 gw 192.168.193.116后，ping的抓包后正常。

   如上图：ping的request和回包reply里目的和源mac地址互换，都正常有回包。

 知识点：

   1，ros路由器可以指定mangle里tzsp端口进行抓包。

   2，ping消息含序号，用来确定是那一包。

   3，Tcpdump命令查看mac地址用-enn，但当使用-i  any时，因为没有指定端口无法获取收发双方的mac地址。

   4，交换机一般不会引起丢包。

  5，这种丢包问题，要么发的时候，有一部分发错地方，要么传输中丢了，要么目的ip没收到，目的网关转发的时候，有一部分发给了另一个mac地址，要么是收的没问题没有丢包，但会响应发给了错误的地方。总之，源设备长ping吗，在源和目的两边都抓包，对比ping的request消息里携带的序号，和没有收到reply包的序号，确定丢在那个环节。检查对应的环节就行了。