奇怪：为什么linux在上次ping回复后会响应ping请求？

我(和一位同事)刚刚注意到并测试过,当 Linux机器被ping时,在最后一次ping之后,它会向启动ICMP ping的机器发起单播ARP请求.在ping到Windows计算机时,Windows计算机最后不会发出ARP请求.

有没有人知道这个单播ARP请求的目的是什么,为什么它发生在Linux而不是Windows上？

Wireshark跟踪(10.20.30.45是一个Linux框)：

No.Time        Source           Destination      Prot  Info
19 10.905277   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
20 10.905339   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
21 11.904141   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
22 11.904173   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
23 12.904104   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
24 12.904137   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
25 13.904078   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
26 13.904111   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
27 15.901799   D-Link_c5:e7:ea  D-Link_33:cb:92  ARP   Who has 10.20.30.14?  Tell 10.20.30.45
28 15.901855   D-Link_33:cb:92  D-Link_c5:e7:ea  ARP   10.20.30.14 is at 00:05:5d:33:cb:92

更新：我刚刚搜索了更多的单播ARP请求,我发现的唯一有用的参考是在RFC 4436,这是关于“检测网络附件”(从2006年).此技术使用单播ARP来允许主机确定它是否重新连接到先前已知的网络.但是我没有看到这是如何因为执行ping而对ARP请求有效.所以神秘感仍然存在……

解决方法

Linux发送各种单播ARP请求来更新它的ARP缓存.这是为了防止过时(和可能是恶意的)ARP缓存条目.

在某些情况下使用单播ARP,基本上是为了验证ARP缓存.如果条目是陈旧的,则后备是广播ARP.

这在RFC1122 2.3.2.1中讨论

我认为这就是它正在做的事情,至于为什么,我的第一个猜测是某种反欺骗措施. ARP数据包永远不会被路由,所以我假设你在本地局域网上这样做了吗？每次ping主机或刚刚跟踪一次时,这种情况是否一直发生？在这种情况下,该主机的ARP缓存可能已经巧合地超时.

您正在ping机器的主机上运行的操作系统是什么？