サーバへの接続ができたり、できなかったり…IP 重複による ARP キャッシュ書き換えと arping 診断手順

公開日 2026/5/31 最終更新日 2026/5/31

「アプリサーバから DB サーバに繋がらない」という障害報告が入った。
確認しに行くと繋がる。しばらく経つと、また繋がらなくなる…。

再現しない断続的な障害ほど、調査が迷走しやすいものです。
この記事では、こうした断続的な接続障害の原因のひとつである ARP キャッシュが書き換わる仕組みと、IP アドレス重複を arping で確定診断する手順を実機ログつきで解説します。

1. 症状
2. 原因の仕組み
- ARP とは何か
- IP 重複で何が起きるか
3. 調査手順（実機ログ）
4. 解消手順
5. よくある Q&A
6. まとめ

1. 症状

APサーバから DBサーバへの新規接続が断続的に失敗するようになりました。

APサーバから DBサーバIP へ ping → タイムアウト（または断続的に通る）
APサーバからゲートウェイへ ping → 応答あり
DBサーバのコンソールから他サーバへは ping が通る
両サーバとも同一 VLAN・同一スイッチに接続
ネットワーク機器の設定変更はなし（と担当者は言っている）

この症状の厄介な点

断続的に発生するため、調査しに行ったときには繋がっていることがあります。DB リスナーの状態確認、DB ログの調査、アプリログの確認と進めても原因が見つからず、迷走しやすい障害です。

2. 原因の仕組み

なぜ、このような障害が発生するのでしょうか。

ARP とは何か

同一セグメント内の通信では、IP アドレスだけではパケットを届けられません。最終的にパケットを届けるには MAC アドレスが必要で、IP から MAC を解決する仕組みが ARP（Address Resolution Protocol） です。

用語	意味
ARP リクエスト	「この IP の MAC アドレスを教えて」というブロードキャスト
ARP リプライ	「私がその IP です。MAC は○○です」という応答
ARP キャッシュ	IP → MAC の対応表。一定時間保持される
GARP（Gratuitous ARP）	「私はこの IP です」と自ら宣言するブロードキャスト。NIC を UP にしたときなどに自動送信される

IP 重複で何が起きるか

同一セグメントに同じ IP を持つホスト（不正ホスト）が現れると、以下の流れで ARP キャッシュが書き換わります。

① 不正ホストが IP を変更して NIC を UP
        ↓
② Linux が自動的に GARP を送信
   「10.0.10.102 は私（MAC: xx:xx:xx）です」（ブロードキャスト）
        ↓
③ APサーバが GARP を受信
   ARP キャッシュの 10.0.10.102 → 不正ホストの MAC に上書き
        ↓
④ APサーバが 10.0.10.102 宛にパケットを送ると、不正ホストに届く

接続が断続的になる理由は ARP キャッシュの向き先次第

ping と DB 接続は、どちらも ARP キャッシュが示す MAC アドレスに向かいます。宛先が変わるわけではありません。

ARP キャッシュが不正ホストを向いているとき
  → ping も DB 接続も、両方とも不正ホストに届く
  → ping は「通る」（不正ホストも Linux なので ICMP に応答する）
  → DB 接続は「失敗」（不正ホストに DB リスナーがないため）

ARP キャッシュが DBサーバ正規を向いているとき
  → ping も DB 接続も、両方とも正規に届く → どちらも成功

この検証では不正ホストは DB リスナーを持たない一般的な Linux VM です。不正ホストが別の DB サーバだった場合、DB 接続自体は成功しますが別の DB に繋がっているという、より気づきにくい障害になります。

症状が断続的になる理由

同じ IP に対して2台が ARP に応答するため、どちらの応答が最後に届くかによって ARP キャッシュが書き換わり続けます。正規 DB を向いているときは接続が成功し、不正ホストを向いているときは接続が失敗する——この繰り返しが断続的な症状として現れます。

3. 調査手順（実機ログ）

それでは実際に調査の流れを確認していきましょう。

検証環境の構成は以下のとおりです。

役割	IP
APサーバ（調査側）	10.0.10.101
DBサーバ（正規）	10.0.10.102（MAC: bc:24:11:a5:27:12）
不正ホスト	10.0.10.103 → 10.0.10.102 に変更して IP 重複を再現

Step 1：ARP キャッシュを確認する

APサーバで arp -n を実行し、DBサーバの IP に対してどの MAC アドレスが登録されているかを確認します。

$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.10.102              ether   bc:24:11:00:78:5f   C                     ens19
10.0.10.103              ether   bc:24:11:00:78:5f   C                     ens19

10.0.10.102 と 10.0.10.103 が同じ MAC（bc:24:11:00:78:5f）を指しています。正規の DBサーバの MAC（bc:24:11:a5:27:12）とは異なります。ARP キャッシュが書き換わっている可能性があります。

arp -n はあくまで「今キャッシュに入っている値」しか見えません。ARP キャッシュは動的に書き換わるため、確認したタイミングによって結果が変わります。

Step 2：arping で IP 重複を確定する

arping を使って、実際に ARP リクエストを投げて返ってきた応答を確認します。

$ arping -I ens19 -c 5 10.0.10.102
ARPING 10.0.10.102 from 10.0.10.101 ens19
Unicast reply from 10.0.10.102 [BC:24:11:00:78:5F]  1.008ms
Unicast reply from 10.0.10.102 [BC:24:11:A5:27:12]  1.037ms
Unicast reply from 10.0.10.102 [BC:24:11:A5:27:12]  0.775ms
Unicast reply from 10.0.10.102 [BC:24:11:A5:27:12]  0.769ms
Unicast reply from 10.0.10.102 [BC:24:11:A5:27:12]  0.775ms
Unicast reply from 10.0.10.102 [BC:24:11:A5:27:12]  0.856ms
Sent 5 probes (1 broadcast(s))
Received 6 response(s)

この結果の読み方

同じ IP（10.0.10.102）から 2 種類の MAC が返ってきた → IP 重複確定
Sent 5 probes に対して Received 6 response(s) → プローブ（arping が送った ARP リクエストの回数）より応答数が多い = 2 台が応答している
BC:24:11:00:78:5F（不正ホスト）→ 第 1 プローブ（ブロードキャスト）に応答
BC:24:11:A5:27:12（DBサーバ正規）→ 第 1 プローブ + ユニキャスト 2〜5 プローブに応答

arp -n はキャッシュの現在値しか見えませんが、arping は実際に ARP を投げて全応答を見せます。キャッシュが上書きされていても IP 重複を検出できるため、確定診断に使います。

Step 3：tcpdump でパケットの到達を確認する

DBサーバ正規で tcpdump を起動し、APサーバからの ICMP が届いているかを確認します。

DBサーバ正規で実行（別ターミナル）：

$ tcpdump -i ens19 icmp &

APサーバから ping を実行：

$ ping -c 5 10.0.10.102

ICMP が届いていれば：DBサーバ正規の ARP 応答が最後に届いており、パケットは正規に届いている状態です。

ICMP が届いていなければ：不正ホストがパケットを奪っている状態です。DB 接続は不正ホストに向かっているため失敗します。

4. 解消手順

不正ホストの IP を修正する

不正ホストで IP アドレスを正しい値に変更します。

$ nmcli con mod ens19 ipv4.addresses 10.0.10.103/24
$ nmcli con up ens19

nmcli con up ens19 実行後、Linux が GARP を自動送信します。ただし、この GARP は .103 に対するものです。.102 のキャッシュが古いまま残っている場合は ip neigh flush dev ens19 で手動クリアするのが確実です。

疎通を確認する

APサーバから ping と ARP キャッシュを確認します。

$ ping -c 3 10.0.10.102
3 packets transmitted, 3 received, 0% packet loss

$ arp -n
10.0.10.102    ether  bc:24:11:a5:27:12  C  ens19

10.0.10.102 が正規の MAC（bc:24:11:a5:27:12）に戻っていれば復旧完了です。

ARP キャッシュが戻らない場合

不正ホストの IP を修正しても ARP キャッシュが古いままの場合は、手動でクリアします。

$ ip neigh flush dev ens19
$ ping -c 3 10.0.10.102

5. よくある Q&A

Q: ARP キャッシュはどのタイミングで更新されるか？

主に 3 つのタイミングで更新されます。

タイミング	説明
自分が通信を開始した	ARP リクエストへのリプライで相手の MAC を学習する
ARP リクエストを受け取った	リクエストには送信者の IP と MAC が含まれるため、受け取ったホストが送信者情報を学習・更新する
GARP を受け取り既存エントリがある	既存のエントリを上書き更新する。既存エントリがない場合は新規作成されない（Linux デフォルト）

Q: arping を実行すると ARP キャッシュが変わることがある？

あります。arping のブロードキャストに対して複数ホストが応答した場合、最後に届いた ARP 応答で ARP キャッシュが上書きされます。調査コマンドが意図せず状況を変化させることがあるため注意が必要です。

Q: この障害が発生しやすいのはどんなケースか？

VM 環境で発生しやすいです。

VM クローン後の IP 変更漏れ
テスト環境から本番環境への VM 持ち込み
構築作業中の IP 設定ミス

「最近 VM の追加・複製・クローン作業はありましたか？」という確認を早めに入れると、IP 重複に行き着くのが速くなります。

6. まとめ

同一セグメント内の疎通問題初動確認テンプレート

$ ping -c 10 <対象IP>              # パケットロス率・RTT のばらつきを確認
$ arp -n                           # ARP キャッシュの MAC アドレスを確認
$ arping -I <NIC名> -c 5 <対象IP>  # ★複数 MAC から応答が返れば IP 重複確定

arping で複数の MAC から応答が返ってきたら IP 重複確定です。ping の次に arping を打つ習慣を持っておくだけで、この種の障害を早期に発見できます。

対応フロー

「サーバへの接続が断続的にできない」
    ↓
arp -n で ARP キャッシュの MAC を確認
    ↓
arping -I <NIC> -c 5 <対象IP> で IP 重複を確認
    ↓
複数 MAC が返ってきたら不正ホストを特定して IP を修正
    ↓
arp -n で正規 MAC に戻っていることを確認 → 疎通回復

注意点