PingのEcho要求とEcho応答は別方向のパケットです。往路が到達しても、宛先のデフォルトゲートウェイ、戻り側ルーティング、ステートフルファイアウォール、NATが正しくなければ応答は送信元へ戻りません。片方向通信を切り分けるときは両端の経路を別々に描きます。
この記事はネットワークエンジニアの仕事内容の各論です。工程の全体像から確認したい場合はそちらへ。
けんと＠設計構築チャンネル
非対称ルーティングを読むときは、宛先だけでなくプレフィックス長、優先度、ネクストホップの順に見ます。経路があるかと、その経路が実際に選ばれるかは分けて考えてください。
Pingの戻り経路は往路と同じ？
先に答えると、PingのEcho要求とEcho応答は別方向のパケットです。往路が到達しても、宛先のデフォルトゲートウェイ、戻り側ルーティング、ステートフルファイアウォール、NATが正しくなければ応答は送信元へ戻りません。片方向通信を切り分けるときは両端の経路を別々に描きます。
非対称ルーティングはどこで生まれる？
それぞれの役割と、実務で見るところを次の表に整理します。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| 往路 | Echo要求 | 送信元経路→中継→宛先 |
| 復路 | Echo応答 | 宛先経路→中継→送信元 |
| ステートフルFW | セッションの往復を追跡 | 想定外インターフェースへ戻ると破棄される場合 |
| NAT | アドレス/ポート変換状態 | 復路が同じ変換装置へ戻る必要 |
送信元PC192.0.2.10
R1往路
FW-Aセッション作成
サーバー203.0.113.10
送信元PC応答を待つ
R1復路
FW-B状態がない場合は破棄
サーバー応答送信
往路と復路が異なる＝非対称ルーティング
Pingは要求が宛先へ届くだけでは成功しません。応答が送信元へ戻る経路も必要です。ステートフルFWやNATをまたぐ場合、復路が別装置を通るとセッション情報と一致せず破棄されることがあります。
片方向通信をどう切り分ける？
作業の順序と、各ステップの完了条件を次の表にまとめます。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 送信元で宛先経路と送信元IPを固定 | どのインターフェースから出るか |
| 2 | 宛先で送信元への経路を確認 | 応答のネクストホップ |
| 3 | 中継FW/NATのセッションを両方向で確認 | 要求と応答のタプル |
| 4 | キャプチャ時刻をそろえて最後の観測点を特定 | 損失区間を狭める |
# Linux source指定
ping -I 192.0.2.10 -c 5 203.0.113.10
ip route get 203.0.113.10 from 192.0.2.10
# Cisco例
show ip route 203.0.113.10
show ip route 192.0.2.10203.0.113.10 from 192.0.2.10 via 192.0.2.1 dev eth0 src 192.0.2.10
64 bytes from 203.0.113.10: icmp_seq=1 ttl=60 time=8.4 msFW・NATでは何を照合する？
症状ごとの原因候補と、次に確認することを次の表にまとめます。正常時の出力と並べて差を見ます。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 要求だけ見える | 宛先ホスト/FWで応答生成不可 | ホストファイアウォール、アドレス、サービス |
| 応答が宛先側から出るが届かない | 戻り経路・ACL・NAT | 逆方向の各ホップ |
| 片方のFWだけセッションなし | 非対称経路 | ルーティング優先度とECMP |
| 送信元指定で結果が変わる | VRF/インターフェースごとの経路差 | 実サービスと同じ送信元で再試験 |
復旧を何で判定する？
『Pingが通らない』を一つの事象にせず、要求がどこまで届き、応答がどこから戻ったかを二本の矢印で記録します。経路変更時は既存セッションと新規セッションの結果を分けます。
- 対象機器・インターフェース・VRF/VLAN
- 取得日時・タイムゾーン・ソフトウェアバージョン
- 変更前後の同一コマンド出力
- 期待値・実測値・判定者
- 異常時の停止条件と切り戻し結果
この内容は、設計構築チャンネルの動画でも解説しています。
関連する記事
まとめ：往路と復路を別々のルーティング問題として確認する
要点は、往路と復路を別々のルーティング問題として確認することです。送信元を明記した実行結果を残さないと、戻り経路の問題かどうかを説明できません。
