下図のようなシナリオがあります。
ここでは、2 台のホスト マシンがハブ経由で接続されています。
さて、ホスト 1 はホスト 2 に ping を実行しようとしており、同じハブに接続された 3 番目のホストに Wireshark を設定しました。驚いたことに、1 つの ping コマンドが機能するのに、4 つのパケットがあるはずなのに 6 つのパケットが表示されました。以下は、Wireshark で表示される内容です。
私の理解を超えているのは、ARP 応答の宛先が送信者の MAC をすでに知っているのに、パケット 5 と 6 が生成される理由です。
それとも私の理解に何か間違いがあるのでしょうか、助けてください。
答え1
元の回答
最初の応答は、ホスト 1 インターフェイスではなく、ハブ インターフェイスから返されます。返信する際には、ホスト 1 の IP を持つインターフェイスの MAC を知る必要があります。スイッチによっては、これを自動的に行うものもあれば、行わないものもあります。
改善された回答:
.-----------.
| hub |
| |
[host-1 i1]+--+hi1 hi2+--+[i2 host-2]
| |
`-----------´
network interfaces:
i1, i2, hi1, hi2
アプリケーション層の IP アドレスを介してホスト 2 からホスト 1 に何かを送信した後、ホスト 2 への最初の応答 (および後続のすべての応答) は、ホスト 1 のインターフェイスでhi2はなく、インターフェイスから送信されますi1。
ホスト 1 の既知の IP に何かを送信するには、ホスト 2 はリンク層でパケットを送信する場所を知る必要があります。そのためには、ホスト 2 はホスト 1 の IP を公開しているインターフェースの MAC アドレスを要求する必要があります。
一部のスイッチはこのような変換を自動的に行い、MACパスを記憶します。後ろ向きほとんどのハブではそうではないので、2 番目のリクエストが発生します。
答え2
与えられた回答は間違っていると思います。私の意見では、この現象は、STALE ARP エントリを検出/回避するための Linux カーネルの ARP 実装によって発生します。送信者の MAC アドレスを学習すると、受信側のローカル ARP キャッシュが更新され、エントリが「DELAY」ステータスで配置されます。約 5 秒間待機した後 (デフォルト、 で変更可能delay_first_probe_time)、受信側は到達可能性をプローブし、ホストが「REACHABLE」と見なされるようになったと判断します。
詳細は以下をご覧ください:
https://osqa-ask.wireshark.org/questions/15792/arp-replies-appear-with-delay-in-wireshark-output/