2番目のARP要求がpingが終了するまで待機するのはなぜですか？
この問題は、100MbカードからギガビットNICに切り替えた後にのみ発生したため、私の教授の1人から提示されました。 pingされているコンピューターからの2番目のarp要求（応答を送り返すため）は、pingが完了するまで送信されません。
自宅でいくつかのVMを使用してテストを行い、原因を見つけることができるかどうかを確認することにしました。
両方のマシンでarpキャッシュをクリアし（arp -d）、pingを実行した後、教授と同じ結果が得られましたが、理由がわからないようです。
私はグーグルをして、Linux（私はWindows 10を使用しています）を使用して同様の問題を抱えている人を見つけました、それはarpテーブル内に古いエントリがあることと最初のプローブ遅延と呼ばれるものがあることについて何かを言いましたが、私は決してできませんでしたWindows用のこれらのいずれかに関する情報を見つけるため。
なぜこれが起こっているのか誰かが知っていますか？または、最初のデバイスが見つからない場合、その2番目のarp要求は何のためにありますか？
これは、ブルース・ハートペンスが「リターンARP」と呼んでいるもののようです。 この抜粋 「パケットガイドからコアネットワークプロトコル」で説明されているように。
図4-12に示す会話は、ARPのもう1つの重要な側面を示しています。会話を発信した（ARPリクエストを生成した）ホストのみが、宛先ホストのエントリをローカルARPテーブルに配置します。つまり、交換を聞いている他のステーションは、ARP要求を受信していても、これらのステーションを自分のARPテーブルに追加しません。 ただし、多くのホスト（特にルーター）は、テーブルへの入力に関して積極的であり、ARPトラフィックを聞いたり、ARPメッセージに関与したりすると、その後、独自のARP要求を生成してテーブルに入力します。 。
短い答え。宛先ホストは、他のホストを認識しているため、自身のARPテーブルにデータを入力しています。