发送方信息在 ARP 请求期间未缓存在接收方上

Question

我目前正在尝试了解更高级的网络概念。我这样做的方法是在我作为系统管理员管理的其中一台服务器上运行并运行网络捕获来查看和理解数据。（我运行此捕获的机器是 serveriamon.networkname.local，IP 为 172.16.2.7）

这使我在网络上进行了这次交流：

1127    11:46:55 12/10/2012 30.2960887      172.16.3.30
serveriamon.networkname.local   ARP ARP:Request, 172.16.3.30 asks for 172.16.2.7    

1128    11:46:55 12/10/2012 30.2961939      serveriamon.networkname.local   172.16.3.30 ARP ARP:Response, 172.16.2.7 at 78-2B-CB-23-8D-07   

我能理解这种交流。位于 172.16.3.30 的机器想要找出 172.16.2.7 的 MAC 位置和内容。位于该地址的服务器（此服务器）回复其包含 Mac 地址的 ARP 响应。

紧接着，此帧随即发生：

1129    11:46:55 12/10/2012 30.2964210      172.16.3.30 serveriamon.networkname.local   SNTP    SNTP:NTPv3 Request, Leap = 0, Mode = 3, RID = 5154  {SNTP:377, UDP:376, IPv4:375}

我理解这是对服务器时间的请求。没关系。下一帧是什么让我困惑：

1130    11:46:55 12/10/2012 30.2972641      serveriamon.networkname.local   172.16.3.30 ARP ARP:Request, 172.16.2.7 asks for 172.16.3.30    

SNTP 请求的第 1129 帧中嵌入的是源地址。为什么服务器会立即进行广播以找出 IP 地址在哪里？

我怀疑我只是误解了这是如何工作的，但我真的很感兴趣。在应该已经有信息的情况下发布 ARP 似乎是“浪费”和“嘈杂”？

Answer 1

这是我以前从未注意到的一个有趣的观察。此行为表明服务器在收到 arp 请求时没有将硬件地址放入其 arp 表中。这是什么类型的操作系统？

最初的ARP RFC 826确实讨论了一些关于“合并标志”的问题：

“请注意，在查看操作码之前，<协议类型、发送方协议地址、发送方硬件地址> 三元组已合并到表中。这是基于通信是双向的假设；如果 A 有某种理由与 B 通信，则B 可能会有某种理由与 A 交谈。”

不过，我无法找到有关合并标志的更多信息。

关于此行为原因的猜测：我猜
您可能这样做的 一个原因是为了防止有人溢出您的 arp 缓存。换句话说，“为了安全起见，我只会在我要求的情况下缓存它”。

否则，人们可能会用许多不同的 IP 来制作一堆 arp 请求并填满表（您可以通过许多其他方法来阻止这种情况，但这似乎是一种可行的简单方法）。