目的と用途
arpコマンドは、ARP（Address Resolution Protocol）テーブルの表示／設定を行う。ARPテーブルとは、イーサネット通信のために用いられるIPアドレスとMACアドレスの対照表だ。多くの場合OSが管理するので、ユーザーの設定を必要とすることはほとんどない。
だが、時として、OSの設定ミスそのほかの理由で、イーサネット通信がうまくいかないことがある。その場合、ARPテーブルの設定に問題がないかどうか、arpコマンドで確認することができる。また、手動によるARPテーブルの管理も行える。
書式
●Windowsの場合
- ――ARPテーブルへの追加
arp -s IPアドレス MACアドレス[ インターフェイス] - ――ARPテーブルの削除
arp -d IPアドレス[ インターフェイス] - ――ARPテーブルの表示
arp -a[ IPアドレス][ -N インターフェイス]
| -s | ARPテーブルへ指定されたIPアドレスとMACアドレスのエントリー追加を行う インターフェイス ARPテーブルが対象とするインターフェイスを指定する。省略された場合は、IPアドレスなどから自動決定する | |
| -d | 指定されたIPアドレスのエントリーを削除する | |
| -a | ARPテーブルを表示する。IPアドレスやインターフェイスが指定された場合は、該当するエントリーのみを表示する |
●Linuxの場合
- ――ARPテーブルへの追加
arp[ -v][ -H ハードウェアタイプ][ -i インターフェイス] -s ホスト名(IPアドレス) MACアドレス[ temp][ nopub] - ――Proxy ARPのためのエントリーの追加
arp[ -v][ -H ハードウェアタイプ][ -i インターフェイス] -s ホスト名(IPアドレス) MACアドレス[ netmask サブネットマスクアドレス] pub
arp[ -v][ -H ハードウェアタイプ][ -i インターフェイス] -Ds ホスト名(IPアドレス) 使用したいMACアドレスを持つインターフェイス[ netmask サブネットマスクアドレス] pub - ――ARPテーブルへのファイルからの一括追加
arp[ -vnD][ -H ハードウェアタイプ][ -i インターフェイスcolor=blue◇] -f[ ファイル名] - ――ARPテーブルの削除
arp[ -v][ -i インターフェイス] -d ホスト名(IPアドレス)[ pub][ nopub] - ――ARPテーブルの表示
arp[ -vn][ -H ハードウェアタイプ][ -i インターフェイス][ -a][ ホスト名(IPアドレス)]
| オプションなし | -aとほぼ同様の表示を行う | |
| -v | 詳細モード | |
| -H | arpは本来イーサネット以外のデータリンク層でも使用できるようにデザインされている。このパラメータで使用するデータリンクのプロトコルをハードウェアタイプとして指定できる。デフォルトはイーサネット（ether）。ほかにトークンリング（tr）なども指定できる | |
| -i | エントリーが対応するインターフェイスを指定する | |
| -s | ARPテーブルへ指定したホスト名（またはIPアドレス）とMACアドレスのエントリーを追加する | |
| temp | このエントリーがキャッシュであり（つまり定期的に削除されるかもしれない）、永続的でないことを示す。省略されると永続的なエントリーとなり、削除されない | |
| nopub | このエントリーがProxy ARPのためのエントリーでないことを示す | |
| netmask | このエントリのサブネットマスクを指定して、あるサブネット全体のためのエントリーであることを示す。ただし、カーネル2.2.0以降では指定できないようだ | |
| pub | このエントリーがProxy ARPのためのエントリーであることを示す | |
| -n | 出力をIPアドレスのみに抑制する（DNS逆引きを行わない） | |
| -D | MACアドレスの代わりにインターフェイスを指定すると、そのインターフェイスのMACアドレスを使用する | |
| -f | 指定したファイルに複数指定されたエントリーを一括追加する。ファイル名が省略されると、「/etc/ethers」が使用される | |
| -d | ARPテーブルから指定されたホスト名のエントリーを削除する | |
| -a | ARPテーブルの内容を表示する。ホスト名が指定されると該当のエントリーのみを表示する |
使用方法
■ARPテーブルの表示
ARPテーブルの内容を参照するには「-a」オプション（またはオプションなし）を指定する。
●Windowsでの使用例
C:\>arp -a |
●Linuxでの使用例
[root@host1 ~]# arp |
ARPテーブルは、基本的にローカルホストが維持しているキャッシュだ。通信を行えば対象ホスト分のエントリーが増え、その後、使用しないエントリーは自動的に削除される様子も確認できるだろう。
自身のイーサネットでの通信時に使用するエントリーが基本だが、LinuxなどではProxy ARPにも対応しているため、外部のホストへ代理応答するためのエントリーも同時に保持されることがある。
- (1) IPアドレス
エントリーのIPアドレス。またはホスト名が表示される - (2) 物理アドレス／ハードウェアアドレス
イーサネットの場合、エントリーのMACアドレス - (3) エントリーのタイプ
OSにより、格納できるエントリーにいくつかの違いがある
| エントリー | 意味 | |
|---|---|---|
| dynamic | 通常のキャッシュ・エントリー。このエントリーが一定期間再利用されない場合は、テーブルから自動削除される | |
| static | 永続的エントリー。キャッシュとは異なり、一定期間再利用されなくとも削除されない。キャッシュ・エントリーは、OSがARPにより取得して格納したエントリーだが、staticはユーザーが明示的に追加したエントリーに限られる |
| エントリー | 意味 | |
|---|---|---|
| C | 通常のエントリー。このフラグだけの場合はエントリーが一定期間再利用されないと、テーブルから自動削除される | |
| M | 永続的エントリー。Windowsのstaticと同義。一定期間再利用されなくとも削除されない | |
| P | Proxy ARP用エントリー。ほかのホストからのARP要求があれば、このエントリー内容を応答する。これ以外のエントリーの情報は、ほかのホストからのARP要求に対して提供されることはない。そのため、Proxy ARP用エントリーは「Publicエントリー」などとも呼ばれる。通常、このエントリーでは、MACアドレスはその応答するインターフェイスのMACアドレスであり、IPアドレスは別のインターフェイスに接続されたネットワークにあるホストのIPアドレスである（つまり、MACアドレスは自身のインターフェイスのものだが、IPアドレスは別のホストのもの） |
- (4) インターフェイス
ARPテーブルはインターフェイスごとに管理されている。Windowsでは、インターフェイスごとにブロック単位でARPテーブルが表示される
■ARPテーブルの追加／削除
ARPテーブルへは、OSによるARPの結果の追加だけでなく、手動によるエントリーの追加や即時削除を行うこともできる。
あまり利用する局面はないだろうが、ARP要求／応答がネットワークを圧迫している場合には、通常のキャッシュ・エントリーではなく、永続的なエントリーを追加してARPの回数を減らすことができるかもしれない。
●ARPテーブルへの追加例（Windowsの場合）
C:\>arp -s 192.168.1.20 00-20-78-d5-b4-2f |
●ARPテーブルへの追加例（Linuxの場合）
[root@host1 ~]# arp -s 192.168.1.100 00:70:98:A8:07:12 |
Windows、Linuxとも、「-s」オプションでの設定で追加されるエントリーは、永続的なエントリーとなる。通常のキャッシュ・エントリーのように、一定期間内に再利用されなくとも、ARPテーブルから自動的に削除されることはない。Linuxでは、「temp」オプションを指定して、通常のキャッシュ・エントリーとして追加することもできる。ただし、これらの手動追加エントリーは、リブート時にはクリアされてしまう。
またLinuxでは、指定したファイルから複数のエントリーをまとめて追加することも出来る。この場合、「-f」オプションを用いる。ファイル名を省略した場合には、「/etc/ethers」ファイルが使用されることになる。
●ARPテーブルへのファイルからの追加例（Linuxの場合）
[root@host1 ~]# arp -f /usr/local/userset/arp_entry |
●アドレス定義ファイルの例
00:20:78:D5:B4:2F server1 |
ARPテーブルからの削除には、「-d」オプションを指定する。指定したIPアドレスのエントリーを削除する。Windowsではワイルドカードも使用できる。
●ARPテーブルからの削除例（Windowsの場合）
C:\>arp -d 192.168.1.20 |
■Proxy ARPの設定
Proxy ARPは、ほかのホスト宛のARP要求に対して、代理で自身のMACアドレスをARP応答する機能だ。おもにルータなどが対応しており、別々のコリジョン・ドメイン（物理ネットワーク）をサブネット分割することなく、仮想的に1つのネットワークに見せかけることができる。「gracious ARP」などと呼ばれているシステムもある。
Linuxでは、Proxy ARPにネイティブで対応しており、複数のインターフェイスを設置したマルチホーム環境などで使用することができる。それ以外のUNIXでは、「proxyarpd」デーモンが別途必要になる場合がある。
設定は簡単で、ARPテーブルにPublicエントリー（Flags Maskでは「P」で表される）を追加するだけだ。例として、下記のようなシステム構成を考えてみよう。元々ネットワークAとネットワークBは1つのセグメントだったが、最近になり両ネットワーク間にルータ代わりのマルチホームのLinuxマシンを設置した。本来はサブネット分割を行わないといけないのだが、ホストの設定をすべて一斉に変更するのは時間がかかるので、Proxy ARPを設定することで、一時的に両ネットワークの疎通を行う。
以下のコマンドをLinuxマシンで実行すると、ARPテーブルにPublicエントリーが追加される。これにより、ホストAからのARP要求に対して、LinuxマシンがホストBの代わりに自身のMACアドレスを応答するようになる。
●ARPテーブルへのPublicエントリーの追加例（Linuxの場合）
[root@host1 ~]# arp -i eth0 -s 192.168.2.10 00:80:98:C8:07:12 pub |
設定後、通常のIP通信が行われるわけだが、LinuxマシンでIPルーティングが有効になっていれば（参考記事「連載：ネットワーク・コマンド 第3回 ルーティングの設定は正しいか？」）、問題なくホストBまで到達できるだろう。また、双方向通信のためにはホストBにもARP応答ができなければならない。上記と逆の設定（ホストAのIPアドレスへの設定）も必要になる。
■ARPとブロードキャスト
ARPテーブルの維持／管理は、多くの場合、OSが自動的に行ってくれる。ユーザーがARPテーブルを確認したり、あるいは任意で定義をするなら、arpコマンドで行うことができる。ただ、ARP自体は非常に簡易な動作であるので、ユーザーが実際にARPテーブルなどを操作する局面は、Proxy ARP設定などを除いてあまりないだろう。
ARPに関連したトラブルは比較的少ないと考えられるが、それが時として単純な設定ミスを呼び、ARPひいてはイーサネット通信における重大な障害を引き起こす可能性もある。中でも最も顕著なのが、サブネットマスクの設定ミス時だ。例を挙げよう。
図2 サブネットマスクの設定にミスがあった場合のルーティング例。本来、ホストBはホストAの「ICMP Request」に対して、直接返答を行うべきなのだが、サブネットマスクの設定ミスにより、ホストAが別のサブネットにあると判断し、デフォルト・ゲートウェイであるルータXへとパケットを転送してしまう
図2のネットワークのサブネットマスクが「255.255.255.0」だった場合に、ホストBで「255.255.255.240」と設定ミスがあったとする。このとき、ホストAからホストBへICMP Request/Replyの往復通信を考えてほしい。
この場合、ホストA（192.168.1.10）はまず、送信先ホストであるホストB（192.168.1.200）のIPアドレスから、パケットの送信先が同一のサブネットだと判断するので、通常通りMACアドレスを知るためにARP要求を送信する。これはそのままホストBへと届けられる。またホストBは、ARP応答をホストAへと送る。ここまでは正常だ。
次に、ホストAはICMP RequestをホストBへと送信する。しかし、これを受け取ったホストBでは、ホストAへICMP Replyを送ろうとするが、ここでホストAが別のサブネットに存在していると判断してしまう。もし、ルーティング・テーブルにデフォルト・ゲートウェイなどが記載されていない場合には、ルーティング失敗となる。だが問題は、ホストBにおいてデフォルト・ゲートウェイとしてルータXが指定されていた場合だ。
ホストBは、デフォルト・ゲートウェイであるルータXへICMP Replyを転送しようとする。そのため、（もしルータXのMACアドレスをキャッシュしていなければ）ルータXに対してARP要求を行い、ルータXはこれに応答する。そしてルータXへICMP Replyを転送するのである。ルータXは、（やはりホストAのMACアドレスをキャッシュしていなければ）ホストAとの間でARP要求／応答を行い、ようやくホストBからのICMP ReplyをホストAへと届けられる。ルータによっては、ホストBはルータを経由しなくともホストAへと直接フレームを届けられることを判断して、ホストBに対してICMP redirectパケットを送信して、経路を正しくするように通知する場合もある（だが、元々ホストBではサブネットマスクの設定が間違っているため、修正することはできないだろう)。
■どこに問題があるのか？
ここでのポイントは、どのホストも異常を感じていないということだ。また、ユーザーから見ても正常に通信できているように見える。だが実際のフレーム数はどうだろう。ホストAからホストBへpingコマンドなどでICMP Request/ICMP Echoの往復通信をするだけなら、ARPテーブルにエントリーがキャッシュさえされていれば、ICMPの往復が2フレーム発生するに過ぎない。ARPを含めても4フレームだ。しかし上記の例では、ARPも含めて最大10フレームにまで膨れ上がってしまう。
さらに、ARP要求が3回行われている点にも注意してほしい。ARP要求は、ブロードキャストという非常にネットワーク全体に負荷をかける処理だ。ブロードキャストのフレームは、ブロードキャスト・ドメイン全体に送出しなければならないし、各ホストは無視をせずに、必ず受け取って判断しなくてはならない。そのため、各ホストやルータはARPテーブルという仕組みで、ARPの発生を極力減らす努力をしているのである。
一見、正常に稼働しているように見えてしまうため、なかなか発覚しにくい問題だが、ブロードキャストが多発してネットワークがダウンしてしまう状況もありえる。これを「ブロードキャスト・ストーム（ブロードキャストの嵐）」などと呼ぶ。
図2ではたった1つのホストが原因での例だったが、もしこれが複数だったら、使用頻度の高いサーバだったら、果たしてどうか。ネットワークが肥大化して、物理ネットワーク内のホスト数が多すぎる場合にも、似たような状態が起こり得る。たかが数字1つのミスと思うなかれ、サブネットマスクはこのように大変重要な要素なのである。
残念ながら、arpコマンドもただそのホストでのARP要求と応答が正常に行われているかどうかを確認するだけなので、こうしたブロードキャスト多発の検知は、常にネットワーク負荷を計測し続けるなど、地味な努力しかすべがない。ポイントとしては、ARP要求はARPテーブルによって回避されることが多いので、特定のホストから同じARP要求が頻繁に繰り返されているようであれば、何らかの設定ミスの可能性が高い。また、ネットワーク上を流れるフレーム全体に占めるARPパケットの割合にも注意しよう。一概にはいえないが、数％程度までで抑えられているのが望ましいだろう。
関連ネットワーク・コマンド／ツール
arp 〜ARPテーブルの表示／設定
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- イーサネット通信は正しく行われているか？
arpによるARPテーブルの確認と設定