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

       先来抽象介绍一下这个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中。 去定位问题又发现日志不够， 继续加， 继续编译， 继续更新。好吧， 这一路波折就不说了， 直接说定位过程。

       初步定位， 根据日志， 我定位到的原因是：在设备S(w.x.y.z.20)中，arp的sendto函数向ip(w.x.z.30)发起请求后， recv收到了回馈， 我很纳闷， 怎么在这个环境下， 居然能recv到东西呢？ 该ip(w.x.z.30)明明是不可达的啊。 追到sendto而recv这一层， 还是没发现原因， 我开始感觉有点吃力了。

       不要气馁， 肯定是有原因的。 我开始觉得， 日志已经不足以分析了， 那还要怎样？ 抓包？ 对了， 就是抓包。 我抓了个包， 发现居然还真有arp回复， 包中的mac地址信息写的一清二楚， 是xx:xx:xx:xx:xx:xx。 于是， 接下来要看这个mac地址是哪个设备的mac。

       接着， 我在测试同事的电脑上ping了一下w.x.y.30这个ip, 期望arp缓存表中有xx:xx:xx:xx:xx:xx的信息， 果然有， 再看看它对应的ip,  我大吃一惊， 是网关w.x.y.1, 而不是我们arp的对象w.x.y.30。 原来是网关w.x.y.1在回复arp啊， 好神奇。

       我还是百思不得其解， 网关怎么会自动去arp回复ping不通的ip(w.x.y.30)呢？  上网查找， 没查到结果， 于是去问请教另外一个同事， 他经验足。 他解答说： “她们那个局域网的网关就是这样的（比较特殊）， 之前碰到过好几次类似的情况。”  好吧， 现在是弄清了， 人证物证都在， 总算是有底气和测试的MM沟通了

       最后结论： 本问题属于非问题， 原因是blablablabla...

       感叹一句， 要是早点抓包就好了， 以后要注意啊， 网络问题， 抓包抓包抓包。