我有一個如下所示的場景。
這裡兩台主機透過集線器連接：
好的，所以主機 1 想要 ping 主機 2，而且我在連接到相同集線器的第三台主機上設定了wireshark。現在令人驚訝的是，對於單一 ping 命令的工作，我看到 6 個資料包，而應該有 4 個。
現在超出我理解的是，為什麼封包 5 和 6 是在不在 ARP 回覆目標上時產生的，並且已經知道發送者 mac 了。
或是我的理解有問題，請幫忙。
答案1
原答案
第一個回應來自集線器接口，而不是 host-1 接口。當發回資料時，您仍然需要知道具有 host-1 IP 的介面的 mac。有些交換機會會自動執行此操作，有些則不會。
改進的答案：
.-----------.
| hub |
| |
[host-1 i1]+--+hi1 hi2+--+[i2 host-2]
| |
`-----------´
network interfaces:
i1, i2, hi1, hi2
在應用層中透過 IP 位址從主機 2 向主機 1 發送某些內容後，對主機 2 的初始回應（以及所有後續回應）將來自該hi2接口，而不是i1主機 1 中的介面。
為了將任何內容傳送到主機 1 的已知 IP，主機 2 仍然需要知道在連結層上將封包傳送到哪裡。為此，host-2 必須請求不包含 host-1 IP 的介面的 MAC 位址。
有些交換機會會自動進行這種轉換 - 它們會記住 mac 路徑向後。大多數集線器都沒有，因此第二個請求。
答案2
我相信給的答案是不正確的。在我看來，這種現象的發生是由於 Linux 核心的 ARP 實作來尋找/避免 STALE ARP 條目。一旦獲知發送方的 MAC 位址，它就會更新接收方的本機 ARP 緩存，並將該條目置於「延遲」狀態。等待大約 5 秒（預設值，可以在 中更改delay_first_probe_time）後，接收器將探測可達性，然後確定主機現在被視為「可達」。
更多詳情可在此找到：
https://osqa-ask.wireshark.org/questions/15792/arp-replies-appear-with-delay-in-wireshark-output/