目录
1 现象
2 Ping的过程:
3 可能的原因:
4 排查过程
类似问题:ip冲突问题解决和复现过程_wj31932的博客-CSDN博客
无法上网故障排查过程及复现过程系ip冲突造成_wj31932的博客-CSDN博客_arp获取不到网关mac地址
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 可能的原因和解决方法:
- 前向源ip广播域或者后向目的ip广播域环境有设备冒充网关,导致有时ping的request发给错误的mac地址,而不是正确的网关设备,目的ip没有收到request而没有回reply,源设备等待超时。还有可能是源ip或目的ip设备的路由指向问题,比如双默认路由,也可能造成ping的部分request或reply去了另一个mac地址,而终结在这个设备上造成丢包。
- 目的ip环境存在ip冲突,目的网关把部分request消息发给错误的mac地址,导致真正的目的ip没有收到,而没有回reply,源设备等待超时。
- 源ip设备环境中存在ip冲突,导致网关把部分ping的reply消息发给错误的mac地址,源ip等待超时。
- 经过的中间节点网络拥塞或者目的设备处理能力拥塞,导致丢失部分前向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故障处理方法和过程仿真https://blog.csdn.net/wj31932/article/details/97016130
为了获得谁和他冲突了,让他还把地址设置为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表的更新的条件文章来源:https://www.toymoban.com/news/detail-811974.html
在实际的环境中,只有同时满足以下两个条件时,设备的ARP表项才会更新:
1,设备收到来自某IP的ARP请求包或免费ARP包;
2,设备的现有ARP表项中已经存在该IP对应的ARP表项。
其他的非ARP报文不会对设备的ARP表项产生影响。请求包可以单播也可以是广播,只要原来缓存里有内容,不管这个arp请求目的ip是否是自己,都会更新缓存。文章来源地址https://www.toymoban.com/news/detail-811974.html
到了这里,关于ip地址冲突导致ping时通时断显示超时问题处理过程的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!