ip连接 redis windows ip连接超时

目录

1 现象    

2 Ping的过程：

   3 可能的原因：

4 排查过程

---

1 现象    

       一天，同事反馈他的pc出现ping外网时通时断，一会正常打印，一会time out，询问可能原因？

   现象如下图：

  

   看到时通时断，断开是time out，请求超时，自身是192.168.207.0/24网段的，目的ip是172.16.4.111要发给网关192.168.207.1的。

2 Ping的过程：

       就是源ip发出ping的request消息给目的ip，消息里含一窜字符串，经过前向路径到达目的ip。每发一个ping的request都有一个seq的序号。目的ip收到ping的request后，ip地址源和目的调换，发出ping reply消息，经过后向路径，reply消息里把收到request里的那一串字符串镜像发射回去。源设备收到后，打印ping的结果，来回时间，ttl值等。发出request后，等待reply消息，windows是5秒，5秒收不到，打印time out超时。

通常，每一个ping的request都有一个序号，收到的序号和发出需要一致，才能打印ping正常。

用跟踪工具检查经过节点设备：

       这种时通时断，前向丢失没有ping的request消息目的ip没有收到。 要么后向丢失，ping的reply从目的ip发出，而后向路径丢失，源ip没有收到。

   3 可能的原因和解决方法：

1. 前向源ip广播域或者后向目的ip广播域环境有设备冒充网关，导致有时ping的request发给错误的mac地址，而不是正确的网关设备，目的ip没有收到request而没有回reply，源设备等待超时。还有可能是源ip或目的ip设备的路由指向问题，比如双默认路由，也可能造成ping的部分request或reply去了另一个mac地址，而终结在这个设备上造成丢包。
2. 目的ip环境存在ip冲突，目的网关把部分request消息发给错误的mac地址，导致真正的目的ip没有收到，而没有回reply，源设备等待超时。
3. 源ip设备环境中存在ip冲突，导致网关把部分ping的reply消息发给错误的mac地址，源ip等待超时。
4. 经过的中间节点网络拥塞或者目的设备处理能力拥塞，导致丢失部分前向request或者后向reply消息，或者目的设备未响应request消息，导致源设备等待超时。

最好进行ping测试，同时抓包，关注ping消息里序号，具体那个序号的ping request没有得到响应？

        排除是否有设备冒充网关，可以在不通时，arp  -a查看网关mac地址，并在抓包过滤网关的arp消息，看是否有设备通过发送arp消息，使得本机的网关mac地址发送改变，而导致ping的request消息发给了错误mac地址？

        排除本地广播环境中是否存在和本设备ip冲突，可以通过拔插网线，激发本机网卡断开，激活后发出arp的冲突探查消息，若冲突就会把本机ip变成169.254.xxx.xxx,插拔后，本机ip发生变化，就证明本地环境中存在ip冲突。 从抓包里能看出冲突主机的mac地址。

4 排查过程

    自己确定ping了一下，发现正常，如下图：

排除里可能性2，4条。

     让他ping的同时抓包，然后过滤icmp看看。已知他的pc的ip设置为192.168.207.231/24,对应mac地址e0:be:03:21:60:e2。gw是192.168.207.1，对应mac c8:50:e9:67:fa:0c。他反馈过滤ip.addr==172.16.4.111后，如下图：

      发现ping的request的目的mac地址和网关的mac一致，收到reply的序号seq和同一seq的request消息里的源和目的mac是对调的。说明环境里没有冒充网关ip的设备。排除了可能性1。

      但有问题，ping的seq序号不连续，时间上也不是1秒一个。

他反馈，ping这个172.16.4.111，有时就正常了，没有丢包。但过一会又不行了，他ping百度。

      估计环境中有人和他的ip冲突了，符合可能性3，导致ping的reply被回到其他mac地址去了。这镜像接入交换机的包一看就明晰了。当时，忙其他事情，没时间处理，打发他重启pc再看看。

   一会回来，发现他反馈，重启后，pc的ip变成169.254.223.184，无法上网。

查看pc是手动设置的ip192.168.207.231

      同时反馈，改成ip地址自动获取就正常了。

       明白了，这是环境里有人的设备和他ip冲突，因为重启时，设置为静态ip网卡激活，会询问环境中是否有人使用这个ip地址？而发出arp请求查询消息，有人使用这个ip会响应arp请求，告知自身的mac地址。这时，操作系统会把地址置成169.254.xx.xx的本地链路地址。

参考：    ip地址变成169.254.x.x故障处理方法和过程仿真

为了获得谁和他冲突了，让他还把地址设置为192.168.207.231，抓包，再插上网线。提供的抓包查看如下图：

过滤arp contains  c0a8-cfe7  即过滤arp消息里含地址为192.168.207.231的包

发现有一个mac地址和他的192.168.207.231冲突了。

冲突后，网卡会使用169.254的ip地址，过滤bootp  || arp contains  e0:be:03:21:60:e2后如下图：

  如上图：关闭dhcp的地址后，使用静态地址，会进行ip冲突检测，发现冲突后，使用本地链路地址169.254.xx.xx,同样进行ip冲突检测，不冲突后，使用该地址，发出免费arp消息，并请求网关mac，网关不受理本地链路地址的arp请求，所以会用169.254.223.184的地址不断重发arp请求。

   明显了ip冲突了，得找出这个冲突的地址，在接入交换机上查找，确定物理位置。

   确定在这个位置，让他去找人更改地址。

问题解决。

回头看第一个抓包里的ping序号不连续问题，询问地址，当时，他还ping了一个百度的地址。回到第一抓包，过滤icmp消息看看：

  dns  contaisn  baidu   ||  icmp

seq是连续的，但一个seq会发出两个，不知道原因。

在第一个抓包里过滤arp消息，其实也会发现问题：

过滤arp  contains  c0a8-cfe7   ||  icmp

只要Address: 58:48:49:2f:fe:6b给网关发出arp请求，就会出现ping不通

只要e0:be:03:21:60:e2 (e0:be:03:21:60:e2)发出arp，就会有响应

原因是arp消息会更新网关的arp的对应表，更新为不正确的mac地址，导致ping的reply被发给了错误的设备，而真实的设备收不到ping的reply而超时。

结论：

ARP表的更新的条件

在实际的环境中，只有同时满足以下两个条件时，设备的ARP表项才会更新：
1，设备收到来自某IP的ARP请求包或免费ARP包；
2，设备的现有ARP表项中已经存在该IP对应的ARP表项。
其他的非ARP报文不会对设备的ARP表项产生影响。请求包可以单播也可以是广播，只要原来缓存里有内容，不管这个arp请求目的ip是否是自己，都会更新缓存。