この記事は、 「ネットワーク中級編|構築・検証・障害切り分けを身につける」 の第33回です。
前回学んだWiresharkの基本操作を使い、ARP RequestとARP Replyを実際のパケットから読み解きます。
ARPをパケットで確認する|WiresharkでRequest・Replyを読み解く
「Who has ~?」と「~ is at ~」は何を表しているのか。 WiresharkでARP通信を取得し、ブロードキャストのRequest、ユニキャストのReply、 EthernetヘッダーとARPヘッダーの各項目を、障害切り分けにつながる形で確認します。
ARPは、IPv4アドレスから同一リンク上で使用するMACアドレスを調べる仕組みです。 用語として理解していても、実際のパケットを見ると「どのアドレスがブロードキャストなのか」 「Replyは誰に返るのか」で迷うことがあります。
この記事では、ARPキャッシュを確認・削除し、pingを発生させ、WiresharkでRequestとReplyを読む ところまでを一連の検証として行います。
この記事を読み終えるとできること
- ARP RequestとARP ReplyをWiresharkで見分けられる
- EthernetヘッダーとARPヘッダーの宛先を区別できる
- 同一セグメント通信と別セグメント通信でARP対象が変わる理由を説明できる
- ARP Requestだけが繰り返される状況から原因候補を絞り込める
ARPをパケットで確認すると何が分かるのか
正常なARPでは、端末がブロードキャストでMACアドレスを問い合わせ、 対象機器が通常はユニキャストで自分のMACアドレスを返します。
IPv4通信では、IPパケットをEthernetフレームに格納して同一リンク上へ送るため、 次に渡す相手のMACアドレスが必要です。端末がそのMACアドレスを知らない場合にARPを使用します。
ARP RequestとARP Replyの基本動作
00:11:22:33:44:55
aa:bb:cc:dd:ee:ff
「192.168.10.1を持っている機器は、192.168.10.10へ教えてください」
「192.168.10.1のMACアドレスはaa:bb:cc:dd:ee:ffです」
パケットキャプチャーでARPを確認すると、単に「pingが失敗した」という結果だけではなく、 その前段階である同一リンク上の相手を見つけられているかを判断できます。
ARP Replyまで返っていれば、少なくとも対象MACアドレスを解決できる範囲のLayer 2通信は成立しています。
その後にpingが失敗する場合は、IP設定、ICMP制御、ACL、ファイアウォール、ルーティングなどへ確認範囲を進めます。
ARPはIPv4で使用されます。IPv6ではARPではなく、ICMPv6を利用するNeighbor Discovery Protocol(NDP)が同様の役割を担います。
今回の検証構成
最も再現しやすいように、PCから同一LAN上のデフォルトゲートウェイへpingを送ります。 実際のIPアドレスやMACアドレスは、利用している環境に読み替えてください。
検証用の構成例
MAC:00:11:22:33:44:55
MAC:aa:bb:cc:dd:ee:ff
| 項目 | 今回の値 | 確認方法の例 |
|---|---|---|
| 検証PCのIPv4アドレス | 192.168.10.10/24 | Windows:ipconfig |
| デフォルトゲートウェイ | 192.168.10.1 | Windows:ipconfig |
| PCのMACアドレス | 00:11:22:33:44:55 | Windows:getmac または ipconfig /all |
| ARP確認対象 | 192.168.10.1 | 同一LAN上のルーター |
パケットキャプチャーは、自分が管理する端末・検証環境、または許可を得たネットワークで実施してください。
業務ネットワークでは、通信内容や端末情報が含まれるため、取得範囲・保存先・共有方法にも注意が必要です。
WiresharkでARPを取得する手順
ARPキャッシュに対象のMACアドレスが残っていると、新しいARP Requestは発生しません。 そのため、現在のキャッシュを確認し、対象エントリーだけを削除してから通信を発生させます。
-
検証PCのIPアドレスとゲートウェイを確認する
Windowsではコマンドプロンプトを開き、
ipconfigを実行します。 -
現在のARPキャッシュを確認する
arp -aを実行し、対象IPアドレスのエントリーがあるか確認します。 - 対象のARPキャッシュを削除する 管理者権限のコマンドプロンプトで、対象IPアドレスだけを削除します。
- Wiresharkで使用中のインターフェースを選ぶ EthernetまたはWi-Fiのうち、現在通信に使用しているインターフェースでキャプチャーを開始します。
-
表示フィルターへ
arpを入力する ARPだけを表示し、RequestとReplyを見つけやすくします。 - 対象IPアドレスへpingを実行する 今回はデフォルトゲートウェイの192.168.10.1へpingを送ります。
- キャプチャーを停止し、2つのARPパケットを確認する 通常はRequestに続いてReplyが表示されます。
1.IP設定を確認する
C:\> ipconfig
イーサネット アダプター Ethernet:
IPv4 アドレス . . . . . . . . . . : 192.168.10.10
サブネット マスク . . . . . . . . : 255.255.255.0
デフォルト ゲートウェイ . . . . . : 192.168.10.1
2.ARPキャッシュを確認・削除する
C:\> arp -a
インターフェイス: 192.168.10.10 --- 0x8
インターネット アドレス 物理アドレス 種類
192.168.10.1 aa-bb-cc-dd-ee-ff 動的
対象エントリーが表示されている場合は、管理者権限で次のコマンドを実行します。
C:\> arp -d 192.168.10.1
arp -d *で全エントリーを削除する方法もありますが、業務端末では不要な通信再発生につながります。
検証では、可能な限り対象IPアドレスだけを削除してください。
3.Wiresharkでキャプチャーを開始する
Wiresharkを起動し、通信量のグラフが動いているインターフェースを選択します。 キャプチャー開始後、表示フィルターへ次を入力します。
arp
ARPの後に続くpingまで一緒に確認したい場合は、次の表示フィルターを使用します。
arp || icmp
4.pingで通信を発生させる
C:\> ping 192.168.10.1
ARPキャッシュが削除されていれば、最初のICMP Echo Requestを送る前にARPによるMACアドレス解決が発生します。
| No. | Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|---|
| 1 | 0.000000 | 192.168.10.10 | Broadcast | ARP | Who has 192.168.10.1? Tell 192.168.10.10 |
| 3 | 0.001118 | 192.168.10.10 | 192.168.10.1 | ICMP | Echo (ping) request |
| 4 | 0.001509 | 192.168.10.1 | 192.168.10.10 | ICMP | Echo (ping) reply |
一覧の流れがARP Request → ARP Reply → ICMP Echo Request → ICMP Echo Replyとなっていれば、 MACアドレスを解決してからpingが開始されたことを確認できます。
ARP Requestの読み方
ARP Requestは、問い合わせ対象のMACアドレスが分からない状態で送信します。 どの機器が対象IPアドレスを持っているか分からないため、Ethernetフレームの宛先MACアドレスは ブロードキャストになります。
- ▼ Ethernet II
- Destination: ff:ff:ff:ff:ff:ff (Broadcast)
- Source: 00:11:22:33:44:55
- Type: ARP (0x0806)
- ▼ Address Resolution Protocol (request)
- Hardware type: Ethernet (1)
- Protocol type: IPv4 (0x0800)
- Hardware size: 6
- Protocol size: 4
- Opcode: request (1)
- Sender MAC address: 00:11:22:33:44:55
- Sender IP address: 192.168.10.10
- Target MAC address: 00:00:00:00:00:00
- Target IP address: 192.168.10.1
確認ポイント1:Ethernetの宛先はブロードキャスト
Ethernet IIのDestinationはff:ff:ff:ff:ff:ffです。
同じブロードキャストドメインにいる機器へ広く配信し、対象IPアドレスを持つ機器に応答を求めます。
確認ポイント2:Opcodeはrequest(1)
ARPヘッダーのOpcodeが1であればARP Requestです。
Wiresharkではrequest (1)と表示されます。
確認ポイント3:Target MAC addressはゼロ
Requestを送る時点では対象MACアドレスが分からないため、ARPヘッダー内のTarget MAC addressは
00:00:00:00:00:00です。
Ethernetヘッダーの宛先MACと、ARPヘッダー内のTarget MACは別の項目です。
Requestでは、Ethernetの宛先はff:ff:ff:ff:ff:ff、ARP内のTarget MACは
00:00:00:00:00:00となる点を区別してください。
Info欄を日本語にするとどうなるか
| Wiresharkの表示 | 意味 |
|---|---|
Who has 192.168.10.1? |
192.168.10.1を持つ機器は誰か |
Tell 192.168.10.10 |
回答は192.168.10.10へ返してほしい |
ARP Replyの読み方
Requestを受信した機器のうち、Target IP addressを自分が持っている機器がReplyを返します。 Requestから送信元PCのMACアドレスが分かるため、Replyは通常、そのPCだけを宛先としたユニキャストです。
- ▼ Ethernet II
- Destination: 00:11:22:33:44:55
- Source: aa:bb:cc:dd:ee:ff
- Type: ARP (0x0806)
- ▼ Address Resolution Protocol (reply)
- Hardware type: Ethernet (1)
- Protocol type: IPv4 (0x0800)
- Hardware size: 6
- Protocol size: 4
- Opcode: reply (2)
- Sender MAC address: aa:bb:cc:dd:ee:ff
- Sender IP address: 192.168.10.1
- Target MAC address: 00:11:22:33:44:55
- Target IP address: 192.168.10.10
確認ポイント1:Ethernetの宛先はPC-AのMACアドレス
ReplyのDestinationは00:11:22:33:44:55です。
Requestの送信元MACアドレスを使い、問い合わせ元へ直接返しています。
確認ポイント2:Opcodeはreply(2)
ARPヘッダーのOpcodeが2であればARP Replyです。
Requestの1とセットで覚えると判断しやすくなります。
確認ポイント3:Sender MACが求めていた答え
ReplyのSender IP addressが192.168.10.1、Sender MAC addressが
aa:bb:cc:dd:ee:ffです。つまり、PC-Aが知りたかった対応関係は次のとおりです。
192.168.10.1 = aa:bb:cc:dd:ee:ff
このReplyを受信したPC-Aは、対応関係をARPキャッシュへ一定時間保存します。 直後の通信ではキャッシュを利用できるため、毎回ARP Requestを送る必要はありません。
ARPヘッダーの各フィールド
障害切り分けでは、Info欄だけでなくARPヘッダーの詳細も確認できると、 「誰が、何を問い合わせ、誰へ答えたか」を正確に整理できます。
| フィールド | 今回の値 | 意味 |
|---|---|---|
| Hardware type | Ethernet(1) | 使用するリンク層の種類 |
| Protocol type | IPv4(0x0800) | 解決対象となるネットワーク層プロトコル |
| Hardware size | 6 | MACアドレスの長さ。6バイト |
| Protocol size | 4 | IPv4アドレスの長さ。4バイト |
| Opcode | Request=1/Reply=2 | 問い合わせか応答かを識別 |
| Sender MAC address | 送信者のMAC | このARPを送信した機器のMACアドレス |
| Sender IP address | 送信者のIPv4 | このARPを送信した機器のIPv4アドレス |
| Target MAC address | Requestでは通常ゼロ | 対象機器のMACアドレス |
| Target IP address | 調べたいIPv4 | MACアドレスを知りたい対象IPアドレス |
EtherTypeにも注目する
Ethernet IIヘッダーのTypeは0x0806です。これは、Ethernetフレームの中身がARPであることを示します。
一方、ARPヘッダー内のProtocol typeは0x0800で、解決対象がIPv4であることを示します。
Ethernet Type:0x0806
このEthernetフレームのペイロードがARPであることを表します。
ARP Protocol type:0x0800
ARPによって対応するアドレスを調べるネットワーク層プロトコルがIPv4であることを表します。
どちらにも「Type」が登場しますが、確認している階層と意味が異なります。 パケット詳細では、どのヘッダー内の項目かを意識してください。
別セグメント宛て通信では誰をARPするのか
ARPで最も重要な理解ポイントの一つが、別ネットワーク上のサーバーへ通信するときの動作です。
宛先が別セグメントにある場合、PCは遠隔サーバーのMACアドレスではなく、 次にパケットを渡すデフォルトゲートウェイのMACアドレスをARPで調べます。
別セグメント上のWebサーバーへ通信する例
| 通信先 | ARPで調べる対象 | 理由 |
|---|---|---|
| 同一セグメント上の端末 | 最終宛先端末のMACアドレス | Ethernetフレームをその端末へ直接届けるため |
| 別セグメント上の端末 | デフォルトゲートウェイのMACアドレス | まずルーターへEthernetフレームを渡すため |
サブネットマスク設定ミスがARPに現れることがある
PCのサブネットマスクが誤って広く設定されていると、本来は別セグメントにあるIPアドレスを 「同一セグメントにいる」と判断し、その遠隔IPアドレスへARP Requestを送ることがあります。
例:PCが192.168.10.10/16と誤設定されている場合、192.168.20.50を同一セグメントと判断し、
ゲートウェイではなく192.168.20.50自身をARPしようとします。
Requestが繰り返されてもReplyが返らず、通信できません。パケットからサブネットマスク設定ミスを疑える典型例です。
ARPが表示されないときの確認ポイント
pingを実行してもARPが表示されない場合、必ずしも異常とは限りません。 まず、端末がすでにMACアドレスを知っていないか確認します。
原因1:ARPキャッシュが残っている
対象IPとMACの対応関係がキャッシュにあるため、新しいRequestを送らずに通信できます。
arp -aで確認し、対象エントリーを削除して再試行します。
原因2:別のインターフェースをキャプチャーしている
有線LANで通信しているのにWi-Fiを選択しているなど、実際の送信インターフェースとキャプチャー対象が一致していない可能性があります。
原因3:表示フィルターが誤っている
arp以外の条件が組み合わさっていると、取得済みでも表示されない場合があります。一度フィルターを削除して確認します。
原因4:通信が発生していない
pingコマンドの対象IPを間違えた、コマンドが実行されていない、アプリケーションがキャッシュを利用しているなどを確認します。
キャッシュあり・なしの違い
| 状態 | 最初に見えるパケット | 説明 |
|---|---|---|
| ARPキャッシュなし | ARP Request | MACアドレスを解決してからIP通信を開始する |
| ARPキャッシュあり | ICMPやTCPなど | 保存済みMACアドレスを使用するためARPを省略できる |
ARPを使った障害切り分け
ARPは、Layer 2とLayer 3の境界を確認するうえで非常に有効です。 パケットの有無とRequest/Replyの組み合わせから、確認範囲を段階的に絞り込みます。
送信されるか
返るか
送信されるか
戻るか
主な確認ポイント
- 正しいインターフェースをキャプチャーしているか
- 対象IPのARPキャッシュが残っていないか
- 端末が対象を同一セグメントと判断しているか
- 通信を実際に発生させているか
- 表示フィルターで除外していないか
主な原因候補
- 対象機器が停止している、またはネットワークへ接続されていない
- PCと対象機器が異なるVLANに所属している
- アクセスポートのVLAN設定、トランク許可VLAN、無線LANの収容先が誤っている
- 対象IPアドレスが誤っている、または重複・未設定である
- PCのサブネットマスクが誤り、本来は遠隔のIPを直接ARPしている
- ポートセキュリティ、Dynamic ARP Inspection、端末間分離などで通信が制限されている
同じRequestが一定間隔で繰り返される場合、端末は「MACアドレスを解決できず、再問い合わせしている」と判断できます。
分かったこと
- 対象IPとMACの対応関係は解決できている
- ARPを送受信できる範囲のLayer 2到達性はある
次に確認する項目
- PCと対象のIPアドレス、サブネットマスク
- ICMPを拒否する端末ファイアウォール
- ACL、ファイアウォールポリシー、ルーティング
- 戻り経路
主な原因候補
- IPアドレスが重複している
- VRRPやHSRPなどの仮想MACアドレスを使用している
- Proxy ARPが動作している
- 機器交換・冗長切り替え後にMACアドレスが変化した
- ARPスプーフィングなど、不正なARP応答が発生している
IPアドレスとMACアドレスの対応が短時間に何度も変化する場合は、単純な通信障害だけでなく、 IP重複、冗長化動作、セキュリティインシデントも含めて調査します。
現場での確認順序
- 端末のIPアドレス・サブネットマスク・デフォルトゲートウェイを確認する
- ARPキャッシュに期待するIPとMACの対応があるか確認する
- WiresharkでRequestの送信を確認する
- Replyの有無と送信元MACを確認する
- Reply後にICMP、TCP、UDPなどのIP通信が続いているか確認する
- スイッチのMACアドレステーブルやVLAN設定と照合する
調査結果の報告例
【事象】 PC-Aからデフォルトゲートウェイ 192.168.10.1 へ通信できない。 【確認結果】 ・PC-AからARP Requestは送信されている。 ・RequestのTarget IP addressは192.168.10.1で正しい。 ・同一Requestが再送されているが、ARP Replyは確認できない。 ・PC-AのIPアドレス/サブネットマスクは設計値と一致している。 【判断】 PC-AはゲートウェイのMACアドレスを解決できていない。 PC-AからRequestを送信できているため、ゲートウェイ側の停止、VLAN不一致、 または途中スイッチの収容設定に原因がある可能性が高い。 【次の確認】 ・ゲートウェイインターフェースの稼働状態 ・PC-A接続ポートとゲートウェイ接続ポートのVLAN ・スイッチのMACアドレステーブル ・ポートセキュリティ/ARP検査機能のログ
Gratuitous ARPとARP Probe
WiresharkでARPを見ていると、通常の「相手のMACアドレスを知りたい」という通信以外も表示されます。 代表的なものがGratuitous ARPとARP Probeです。
Gratuitous ARP
自分自身のIPアドレスとMACアドレスの対応を周囲へ通知するARPです。 IP重複の検知、ARPキャッシュの更新、冗長ゲートウェイ切り替え後の通知などに利用されます。
Wiresharkでは、Sender IPとTarget IPが同じアドレスになっているパケットとして見えることがあります。
ARP Probe
端末がIPアドレスを正式に使用する前に、そのIPアドレスがすでに使われていないか確認するためのARPです。
送信元IPアドレスが0.0.0.0、Target IPが確認したい候補アドレスとして表示されます。
冗長化切り替え時にARPを見る
VRRPやHSRPなどでアクティブ機器が切り替わると、仮想IPに対応するMACアドレスの情報を更新するため、 Gratuitous ARPが送信されることがあります。
切り替え後も通信が旧機器へ向かう場合、Gratuitous ARPが送信されたか、端末やスイッチのテーブルが更新されたかを パケットと機器情報の両方から確認します。
Gratuitous ARPは実装や製品によってRequest形式・Reply形式など見え方が異なる場合があります。 単にOpcodeだけで判断せず、Sender IP、Target IP、MACアドレス、送信タイミングを合わせて確認してください。
理解度チェック
記事の内容を確認するため、次の5問に答えてください。
問題1.通常のARP Requestで、Ethernetヘッダーの宛先MACアドレスはどれですか。
- 00:00:00:00:00:00
- ff:ff:ff:ff:ff:ff
- 送信元PCのMACアドレス
- 遠隔サーバーのMACアドレス
解答を見る
対象MACが不明なため、同じブロードキャストドメインへブロードキャストで問い合わせます。
問題2.ARP RequestのARPヘッダー内にあるTarget MAC addressは、通常どの値ですか。
- ff:ff:ff:ff:ff:ff
- 00:00:00:00:00:00
- デフォルトゲートウェイのMACアドレス
- 送信元PCのMACアドレス
解答を見る
Request時点では対象MACアドレスが分からないため、ゼロで表現されます。
問題3.別セグメント上の203.0.113.20へ通信するとき、PCが通常ARPで調べる対象はどれですか。
- 203.0.113.20のMACアドレス
- DNSサーバーのMACアドレス
- デフォルトゲートウェイのMACアドレス
- 自分自身のMACアドレス
解答を見る
PCは最初にIPパケットを渡す次ホップであるデフォルトゲートウェイのMACアドレスを解決します。
問題4.ARP Requestは確認できるものの、同じRequestが繰り返され、Replyがありません。何が分かりますか。
解答を見る
送信元端末は対象IPのMACアドレスを解決できていません。 対象機器停止、VLAN不一致、IP設定誤り、サブネットマスク誤り、セキュリティ機能による制御などを確認します。
問題5.ARP Replyは正常に返っていますが、pingは失敗します。次に確認すべき項目を3つ挙げてください。
解答を見る
回答例:
- 送信元・宛先のIPアドレスとサブネットマスク
- 端末ファイアウォールによるICMP拒否
- ACLやファイアウォールポリシー
- ルーティングと戻り経路
実践演習:ARPパケットから通信状態を判断する
演習1.正常なRequestとReplyを取得する
自分のPCで次の手順を実施してください。
ipconfigでデフォルトゲートウェイを確認するarp -aで現在のARPキャッシュを確認する- 対象エントリーを削除する
- Wiresharkで使用中インターフェースのキャプチャーを開始する
- 表示フィルターへ
arp || icmpを入力する - デフォルトゲートウェイへpingする
- RequestとReplyの各フィールドを記録する
確認すべきポイントを見る
- RequestのEthernet Destinationがff:ff:ff:ff:ff:ff
- RequestのOpcodeが1
- RequestのTarget MACが00:00:00:00:00:00
- ReplyのEthernet Destinationが自分のPCのMACアドレス
- ReplyのOpcodeが2
- ReplyのSender MACがゲートウェイのMACアドレス
- ARP完了後にICMP Echo Requestが送信される
演習2.パケット一覧を読み取る
次のパケットが取得されました。
| No. | Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|---|
| 10 | 0.000000 | 192.168.30.25 | Broadcast | ARP | Who has 192.168.30.1? Tell 192.168.30.25 |
| 11 | 1.018453 | 192.168.30.25 | Broadcast | ARP | Who has 192.168.30.1? Tell 192.168.30.25 |
| 12 | 2.041725 | 192.168.30.25 | Broadcast | ARP | Who has 192.168.30.1? Tell 192.168.30.25 |
質問:この端末で何が起きていますか。原因候補を3つ挙げてください。
解答例を見る
192.168.30.25は、192.168.30.1のMACアドレスを問い合わせていますが、Replyを受信できず再送しています。 そのため、ゲートウェイへEthernetフレームを送信できません。
原因候補:
- 192.168.30.1のインターフェースが停止している
- PCとゲートウェイが異なるVLANに収容されている
- ゲートウェイIPアドレスが誤っている
- 途中スイッチのアクセスポート/トランク設定が誤っている
- 端末間分離やARP検査機能によって通信が破棄されている
演習3.別セグメント通信のARP対象を答える
PC-Aの設定は次のとおりです。
| PC-A | 10.10.10.20/24 |
|---|---|
| デフォルトゲートウェイ | 10.10.10.1 |
| 通信先サーバー | 10.20.20.50 |
質問:PC-Aが最初にARPでMACアドレスを調べるIPアドレスはどれですか。また、その理由を説明してください。
解答を見る
ARP対象:10.10.10.1
10.20.20.50はPC-Aと異なるセグメントにあるため、PC-Aは最終宛先のMACアドレスを直接調べません。 最初にIPパケットを渡す次ホップであるデフォルトゲートウェイ10.10.10.1のMACアドレスをARPで解決します。
自分の言葉で説明する課題
後輩から「別ネットワークのWebサーバーへアクセスするのに、なぜゲートウェイへARPするのですか」と質問されました。 60秒程度で説明してください。
説明例を見る
ARPは、同じリンク上で次にEthernetフレームを渡す相手のMACアドレスを調べるために使います。 Webサーバーが別ネットワークにある場合、PCはサーバーへ直接フレームを届けられません。 まず同じネットワークにいるデフォルトゲートウェイへフレームを渡し、ルーターに中継してもらいます。 そのため、IPパケットの宛先はWebサーバーのままですが、Ethernetフレームの宛先MACはゲートウェイになります。
まとめ
- ARPは、IPv4アドレスと同一リンク上で使用するMACアドレスの対応を解決する
- ARP RequestはEthernetブロードキャストで送信され、Opcodeは1
- RequestのEthernet宛先はff:ff:ff:ff:ff:ff、ARP内のTarget MACは通常00:00:00:00:00:00
- ARP Replyは通常、問い合わせ元へユニキャストで返され、Opcodeは2
- 別セグメント宛て通信では、最終宛先ではなくデフォルトゲートウェイのMACアドレスをARPで調べる
- Requestだけが繰り返される場合、MACアドレスを解決できていない
- Reply後に通信できない場合は、IP設定、ICMP制御、ACL、ファイアウォール、ルーティングへ確認を進める
- ARPが見えない場合は、ARPキャッシュ、キャプチャー対象インターフェース、表示フィルターを確認する
ARPパケットを読めるようになると、「通信できない」をLayer 2の到達性と、その後のIP通信に分けて調査できます。

コメント