ブロードキャストメッセージのARPタイムアウト

Question

ホストH2（10.1.1.3/24）と通信したいソースホストH1（10.1.1.2/24）があるとします。両方のホストが同じサブネットにあるので、H1はARPブロードキャストを送信します。 H2はこのブロードキャストに応答し、最後にH1はH2のMACアドレスを取得します。その結果、通信が確立される。

H2がダウンしている場合、H1はH2からARP応答を受信しません。したがって、H1はARP応答を待つ時間は何ですか？ RFC 826はそのようなタイマーについては話しません。

フォーラムでは、5〜30秒であることがわかりました。それが正しいか？

よろしく、あなたの説明では Sudhansu

Answer 1

あなたは、少なくとも一つのことを欠場。 ARP応答はしばらくの間ARPエントリとしてキャッシュされます。 H2がダウンした後、H1はブラックホールにトラフィックを送ります。この期間は、ランダムの数字がbase_reachable_time/2と3*base_reachable_time/2の間で選択されます。 （ランダムは、異なるデバイスからの要求を時間内に配布するために使用されます）。デフォルトでは、base_reachable_timeは30秒です。

このランダムな時間経過後、H1はARPエントリを更新しようとします。更新は、間隔retrans_time_ms（デフォルトでは1秒）のARP要求を送信することにより、ユニキャストメッセージ（ネットワークへのブロードキャストなしでH1に直接送信）によって実行されます。 ucast_solicit（デフォルトでは3）が失敗した場合、ブロードキャストプローブが実行されます。

ブロードキャストプローブも失敗した場合（mcast_solicitは間隔retrans_time_msで試行）、ARPエントリは不完全と見なされます。このチェック中、カーネルはARPキューのH2へのパケット送信を保持できます。

総括：ARPエントリの再検証

（3 + 3）*プローブが開始された後の経過1000ミリ秒前と有効ではないと考えARPエントリまでの経過

• 15-45秒。