ARPが正しいのに通信できない時に疑うべきポイント【L2正常でも止まる理由】

arp -a で確認するとMACアドレスは正しい。

スイッチのMACテーブルも正常。

それなのに通信できない。

この状態は、

ARPが原因ではありません。

本記事では、

• ARPが正常なことをどう確認するか
• L2が成立しているのに止まる代表パターン
• どこまで到達しているかの確認方法
• どうなれば解決と言えるのか

を実務目線で解説します。

前提：ARPが「正しい」とはどういう状態か

以下が満たされていることが前提です。

• ARPエントリが正しいMACに解決している
• MACアドレスは実在機器のもの
• ARPリクエスト/リプライが正常に流れている（tcpdump確認済）

ここまでOKなら、L2解決は完了しています。

問題はその先です。

疑うべきポイント①：戻り通信が来ていない

典型パターン

• 片方向通信のみ成立
• pingは片方向だけ応答

確認方法

tcpdump -nn host 相手IP

見るべきは：

• 自分→相手 のパケットは出ているか
• 相手→自分 の戻りが来ているか

戻りが来ない場合に疑うもの

• 相手側のルーティング不備
• 非対称ルーティング
• FW/NATのセッション破棄

ARPが正常でも、L3経路が破綻していれば通信は成立しません。

疑うべきポイント②：VLANの誤収容

ARPはブロードキャストで届きます。

しかし実通信はタグ付きVLAN経由の場合があります。

典型例

• アクセスポートとトランクの混在
• Native VLAN不一致

確認方法

• switchport mode
• VLANタグ付きキャプチャ確認

ARPは通るがIP通信は落ちる、という現象が起きます。

疑うべきポイント③：MTU不一致

ARPパケットは小さいため通過します。

しかしIP通信は大きなパケットで断片化・破棄が起きる場合があります。

確認方法

ping -M do -s 1472 相手IP

フラグメント不可で失敗する場合、MTU問題の可能性が高いです。

疑うべきポイント④：rp_filter（Linux特有）

逆引きパスフィルタが有効な場合、

非対称経路の戻りパケットが破棄されます。

確認

sysctl net.ipv4.conf.all.rp_filter

一時的無効化（検証用）

sysctl -w net.ipv4.conf.all.rp_filter=0

これで通信が通れば、非対称ルーティングが原因です。

疑うべきポイント⑤：FW/セキュリティポリシー

ARPは許可されているが、

• ICMPがブロック
• TCPポートが閉じている

というケースもあります。

「ARPが通る＝通信できる」ではありません。

疑うべきポイント⑥：MAC学習の揺らぎ

MACアドレスが短時間でポート間を移動していないか確認します。

show mac address-table | include 対象MAC

MACフラッピングがあると、

• 断続的通信障害
• 一瞬だけ通る

といった症状が出ます。

どこまで到達しているかを明確にする

切り分けの基本は：

1. L2（ARP解決）
2. L3（ルーティング）
3. L4（ポート/セッション）
4. アプリ層

各層で「到達している証拠」を確認します。

解決したと言える状態

• 双方向パケットが確認できる
• 経路が対称であることを確認
• FWログでdenyが出ていない
• MTUテストが成功する

この状態で初めて「ARP以外の問題が解消した」と言えます。

まとめ

ARPが正しいのに通信できない場合、

原因はL3以降にあります。

主に疑うべきは：

• 戻り通信不達
• 非対称ルーティング
• MTU不一致
• rp_filter
• FW制御
• VLAN誤設定

ARPは通信の入口に過ぎません。

「どこまで到達しているか」を可視化することが解決への最短ルートです。