Ethernet

【図解】ARPの仕組みとWindows/Linuxでの仕様,コマンド 〜種類,フォーマット,キャッシュ時間,確認/クリアコマンド〜

ARP (読み方:アープ) とは、IP アドレスに紐付く MAC アドレスを知るために利用するプロトコルです。Ethernet 上で IP 通信をするためには必須のプロトコルです。

ARP の概要

端末 A IP アドレス = 192.168.5.11 , MAC アドレス = 01:23:45:67:89:aa) から同一セグメント内の端末 C (IP アドレス = 192.168.5.13 , MAC アドレス = 01:23:45:67:89:ab) に通信する場合を考えます。

このとき、端末 A は宛先の IP アドレスを 192.168.5.13 と指定しますが、宛先の MAC アドレスが分からないので、このままではレイヤー 2 通信が出来ません

そこで、このとき端末 A は ARP 要求をブロードキャストします。ARP 要求の中には自身の IP アドレスと MAC アドレス情報、および、端末 C の IP アドレス 192.168.5.13 が含まれいます。端末 C は、その ARP 要求を受け取ると、ARP 応答に自分の MAC アドレス (01:23:45:67:89:ab) を格納して、L2 ユニキャストで端末 A に返します。

ARP 応答を受け取った端末 A は自身の内部に持つ ARP テーブルに、192.168.5.13 と 01:23:45:67:89:ab の組合せを記憶すると同時に、LAN インタフェースから、渡したかった Ethernet フレームを端末 C に向けて送出します。

以下にイメージ図を示します。

なお、あまり知られていませんが、ARP 応答を受け取ったときだけでなく、ARP 要求を受け取ったときにも ARP テーブルの更新が実施されます

つまり、端末 A が ARP 要求をブロードキャストすると、ARP 応答をした端末 C はもちろんのこと同セグメントにいる他の全ての端末も、端末 A の IP アドレス、MAC アドレスの組み合わせを記憶します

ARPの種類

ARP には以下の種類があります。

  1. 通常の ARP・・・上記の説明の通り、IP 機器が他の IP 機器への通信が必要なタイミングで ARP 要求をブロードキャストし、その IP を持つ機器が ARP 応答をユニキャストで返信します。
  2. Gratuitous-ARP・・・IP 機器がその宛先に通信するタイミングではなく、自らが積極的に相手に自身の IP アドレスを周知するために ARP を送信します。詳しくはこちらを参照下さい
  3. Proxy-ARP・・・ARP 要求を受信したIP機器が、自身がその IP を付与されていないが、ルート情報を持っている場合に自身の MAC アドレスを ARP 応答します。詳しくはこちらを参照下さい
  4. Reverse-ARP・・・MAC アドレスを元に、IP アドレスを配布する。ただし、この機能は DHCP サーバに置き換わっているため、今はまず使われていません。

ARP テーブル (ARP キャッシュ) のキャッシュ保持時間

一度 ARP 応答により受信した IP/MAC アドレス紐付け情報は、一定時間持ち続けます。

Windows および Linux の実装としては、15 秒から 45 秒の範囲でランダムに決まった時間を保持します。これは IPv6 の ARP 相当である NDP に関する仕様を定めた RFC 4861 に準拠する動作です。

Windows に関しては Micrisoft のブログでその旨が書かれています。

Address Resolution Protocol caching behavior - Windows Server
Describes ARP caching behavior in Window...

Linux に関しては以下のカーネルパラメータにて定められています。

[root@localhost ~]# sysctl net.ipv4.neigh.default.base_reachable_time_ms
net.ipv4.neigh.default.base_reachable_time_ms = 30000

このパラメータの 0.5 倍から 1.5 倍の範囲でキャッシュを保持するというのが man ページに書かれています。

arp(7) - Linux manual page

なので Wireshark 等でパケットキャプチャすると、NW 機器に比べてホストからの『who has <ip>? tell <ip>』という ARP 要求が大量に表示され、多いと感じることもあるかと思います。もしくはそのセグメント内に端末が多すぎて、ARP テーブルが溢れている可能性もあります。

もう少し具体的なシナリオについて、以下で紹介しています。

【ARPトラブル】の原因と対処 ~応答解決しない(incomplete),要求の大量発生~
ネットワークのトラブルシューティングに欠かせない ARP テーブル確認 ARP ...

NW 機器においてはメーカによってまちまちのようで、Cisco のデフォルトはかなり長めで 4 時間となっています。ただし、これは前述の Gratuitous-ARP という MAC アドレス更新を周知する仕組みが働く前提でこのような長い時間を取っています。

WindowsでのARP関連の操作

Windows 端末で ARP テーブルを確認するには、コマンドプロンプトで以下を打ちます。

C:\> arp -a

また、ARPテーブルをクリアするには以下を打ちます。

C:\> arp -d *

ARPのフォーマット

ARP プロトコルのフォーマットを以下に示します。イーサネットを利用する場合、 Ethernet のタイプフィールドは "Ox0806" となります。

ハードウェアタイプ

ARP は、イーサネットだけでなく、様々なレイヤー 2 通信をサポートします。ハードウェアタイプフィールドはどのレイヤー 2 通信を 利用するかを表します。

以下に ARP のハードウェアタイプ値とそれに対応するプロトコルを示します。

ハードウェアタイプ
プロトコル
Ox0001Ethernet
Ox0003Amateur Radio AX.25
Ox0004トークンリング
Ox0006IEEE802.1x
Ox000Fフレームリレー
Ox0010ATM

ARP 要求元プロトコル

ARP は、IP だけでなく様々なレイヤー 3 通信をサポートします。ARP 要求元プロトコルフィールドはどのレイヤー 3 通信を利用するかを 表します。この ARP 要求元プロトコル値とそれに対応するプロトコルは、イーサネットフレームで紹介した"タイプ番号"と同じで、 IPv4 は "Ox0800" となります。

ハードウェアアドレス長

レイヤー 2 通信のアドレスを 8 bit 単位で表します。イーサネットの場合、MAC アドレスの長さである 48 bit を表す "Ox06" が入ります。

プロトコルアドレス長

レイヤー 3 通信のアドレスを 8 bit 単位で表します。IPv4 の場合、IPv4 アドレスの長さである 32 bit を表す "Ox04" が入ります。

オペレーションコード

ARP 要求や ARP 応答などを表現します。ARP 要求は "Ox0001"、ARP 応答は "Ox0002" となります。

以上より、端末Aの ARP 要求と端末Cの ARP 応答をまとめますと、以下のようになります。

Field
端末AのARP要求
端末CのARP応答
Field値
内容
Field値
内容
ハードウェア
タイプ
Ox0001EthernetOx0001Ethernet
ARP要求元
プロトコル
Ox0800IPv4Ox0800IPv4
ハードウェア
アドレス長
Ox0648bitOx0648bit
プロトコル
アドレス長
Ox0432bitOx0432bit
オペレーション
コード
Ox0001ARP要求Ox0002ARP応答
送信元
ハードウェア
アドレス
0123456789aa端末AのMAC
アドレス
0123456789ab端末CのMAC
アドレス
(応答値)
送信元
IPアドレス
C0A8050b端末AのIP
アドレス
192.168.5.11
C0A8050d端末CのIP
アドレス
192.168.5.13
宛先
ハードウェア
アドレス
000000000000
(要求値)
Null0123456789aa端末AのMAC
アドレス
宛先
IPアドレス
C0A8050d端末CのIP
アドレス
192.168.5.13
C0A8050b端末AのIP
アドレス
192.168.5.11

コメント

  1. ふぇん より:

    > 一度 ARP 応答により受信した IP/MAC アドレス紐付け情報は、一定時間持ち続けます。
    > WindowsおよびLinuxにおいては、RFC2461 に従い、15秒から45秒の範囲でランダムに決まった時間を保持します。

    IPv4のMAC保持時間を15-45秒としている情報の出所を調べて
    いました。MSのブログにそんな記述があったのですね。

    RFC2461は、IPv6のNDPの動作について書いているので、IPv4には
    適用されないはずですが、準用してコードを作っているなんて
    MSが書くものだから、混乱させているのですね。

    RFCに沿って動いているとは限らないのに・・・・・。

  2. nesuke より:

    ふぇんさん

    コメントありがとうございます。
    すみません、誤解を招く書き方をしていました。MSのブログには「Windows Vista以降のARPキャッシュの振る舞いは、IPv6 の NDPに関する仕様である RFC4861 に従います」と書かれています。この辺りのニュアンスが出るように記事を修正させて頂きます。

    ご指摘ありがとうございました!

  3. 勉強中 より:

    いつも参考にさせていただいております。

    >つまり、端末 A が ARP 要求をブロードキャストすると、ARP 応答をした端末 C はもちろんのこと、同セグメントにいる他の全ての端末も、端末 A の IP アドレス、MAC アドレスの組み合わせを記憶します。

    とありますが、誤っていませんでしょうか?

    ↓では「ARP応答を返したPC2だけが書き込みます。一方、PC3とPC4は、このやりとりに関与していないので、ARPテーブルには書き込みません。」とあります。

    https://nw.seeeko.com/archives/50559138.html

    そこで、Packet TracerとHyper-Vの仮想マシン群で検証をしてみましたが、ARP応答をしなかったPCのARPキャッシュにはARP要求の送信元マシンの情報は登録されませんでした。

  4. nesuke より:

    >勉強中さん
    コメントありがとうございます。
    この動作は RFC5944 (https://datatracker.ietf.org/doc/html/rfc5944) に記載されています。正確に言うと、Gratuitous ARP と呼ばれる動作仕様なのですが、フォーマットなどはARPとまったく同じで、動作仕様について再定義したものになります。

    —引用—
    any node receiving any ARP packet (Request or Reply) MUST update its local ARP cache with the Sender Protocol and Hardware Addresses in the ARP packet

    間違っているかどうか、というよりかは、この仕様に準拠するか否か、という話ですね。(そういう意味では私の記事は言い切ってしまっていますので、そのご指摘ならその通りです。)

    ただ、私が2,3年前に確認した限りでは Windows でも Linux でも HPE スイッチでも更新されていました。

    ご参考までに。

    • 勉強中 より:

      >この仕様に準拠するか否か、という話ですね。

      そういうことだったのですね。お陰様で理解が深まりました。(RFCまでご提示していただき恐縮するばかりです)

  5. k より:

    “なお、あまり知られていませんが、ARP 応答を受け取ったときだけでなく、ARP 要求を受け取ったときにも ARP テーブルの更新が実施されます。”
    長年NWエンジニアやっていましたが、これは新たな発見でした。ルータ実機でも確認しました。arp要求のブロードキャストを受け取っただけでも更新されるんですね。勉強になりました。ありがとうございました。

    • nesuke より:

      k さん、コメントありがとうございます。
      私もNWエンジニア8年目くらいに ARP がテーブルに乗らない問題を調査中にたまたま知ったものでして、こういった教科書には出てこない現場ならではの知識って共有されにくいよなぁ、と思ったものでした。
      お役に立てたようでよかったです。

タイトルとURLをコピーしました