☰

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

tag-icon • tag-icon networking tcpip arp
ARP 请求期间，发送方信息未缓存在接收方

我目前正在尝试理解更高级的网络概念。我这样做的方法是进入我以系统管理员身份管理的服务器之一并运行网络捕获以查看和理解数据。（我运行此捕获的机器是 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 似乎“浪费”和“嘈杂”？

答案1

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

原本的ARP RFC 826确实就“合并标志”讨论了一些这个问题：

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

但是我很难找到有关合并标志的更多信息。

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

否则，人们可能会制作一堆具有大量不同 IP 的 arp 请求并填满表格（有很多其他方法可以防止这种情况，但这似乎是一种简单的方法）。

相关内容