ping不通某ip, 但向它发arp请求居然有响应?--- 谈谈一个奇葩非问题的定位过程

本文描述了一个局域网内的网络问题,其中一台设备在ping不通某个IP的同时,却能收到该IP的ARP响应。作者通过逐步添加日志、抓包分析,发现实际上是网关在回复ARP请求,揭示了一个特殊的网络配置情况。最终确定这是一个非问题,原因是该局域网的网关有特别的ARP处理机制。
摘要由CSDN通过智能技术生成

       先来抽象介绍一下这个bug单.

       现象: 测试同事发现, 在局域网内, pc(w.x.y.10)和某设备S(w.x.y.z.20)都 ping不通某ip(w.x.z.30), 但设备S(w.x.y.z.20)在检测ip(w.x.y.30)的时候, 居然是通过的。

       我来翻译一下: pc(w.x.y.10)和某设备S(w.x.y.z.20)都 ping不通某ip(w.x.z.30), 但设备S(w.x.y.z.20)向ip(w.x.y.30)发arp请求, 居然收到了回应,从现象和日志中都可以看到, 是收到回复了的。

       背景介绍一下: 该问题只在测试同事所在的局域网内复现, 在其他的局域网(比如我的)内不存在。


        

       当接到这个单的时候, 我感到非常纳闷, 怎么在所有其他地方都不存在问题, 就在你这里存在问题呢? 我初步感觉是测试同事那边环境搭建的问题。 但感觉毕竟是感觉, 没有确凿的正确, 测试同事是不会放过的。 既然怀疑是她们的测试环境问题, 那就有必要拿出足够的证据, 否则, 这个单是走不掉的。

       测试的同事白天要测试, 我要想用他们的环境, 那是不行的, 只能等她们晚上下班后, 我再借用环境。 可是, 借到环境后发现, 日志打印不充分啊。 没办法, 继续在代码中加日志, 编译,更新到设备S中。 去定位问题又发现日志不够, 继续加, 继续编译, 继续更新。好吧, 这一路波折就不说了, 直接说定位过程。


</

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值