この記事は、 「ネットワーク中級編｜構築・検証・障害切り分けを身につける」 の第38回です。
前回の「STP障害の切り分け」に続き、 今回は異なるネットワーク間で通信できないときに、 ルーティングテーブル・ネクストホップ・戻り経路を確認して 原因を絞り込む方法を学びます。
ルーティング障害の切り分け｜経路表・traceroute・戻り経路の確認手順を図解
「同じVLAN内では通信できるのに、別ネットワークへ通信できない」 「ルーティングテーブルには経路があるのにpingが通らない」 という障害では、送信方向だけでなく戻り方向まで確認する必要があります。 この記事では、ルーティング障害を順番に切り分ける方法を、 構成例とコマンド出力を使って解説します。
ルーティング障害でよくある失敗は、 「ルーターに経路があるか」だけを確認して調査を終えてしまうことです。
実際の通信では、送信元から宛先までパケットが届くだけでなく、 宛先から送信元へ応答を返すための経路も必要です。
そのため、 送信元 → デフォルトゲートウェイ → 経路 → ネクストホップ → 宛先 → 戻り経路 の順番で確認することが重要です。
この記事を読み終えるとできること
- ルーティング障害の確認順序を説明できる
- 経路表から実際に使用される経路を判断できる
- ネクストホップへの到達性を確認できる
- tracerouteから確認すべき区間を絞り込める
- 戻り経路不足による片方向通信を判断できる
- スタティックルートとOSPFの障害を切り分けられる
ルーティング障害とは何か
ルーティング障害とは、宛先ネットワークへパケットを転送するための 経路が存在しない、誤っている、または正しいネクストホップへ 転送できない状態です。
ルーターは受信したIPパケットの宛先IPアドレスを確認し、 ルーティングテーブルから転送先を決定します。
そのため、異なるネットワーク間で通信できない場合は、 各ルーターが 「その宛先をどこへ転送しようとしているのか」 を確認します。
ルーティングテーブルを見る目的は、 「経路があるか」だけを確認することではありません。
実際に選択される経路、ネクストホップ、 出力インターフェースまで確認します。
まず全体の確認順序を理解する
次の構成で、PC-AからPC-Bへpingできないケースを考えます。
ルーティング障害の基本構成
復路：PC-B → R2 → R1 → PC-A
この通信を調査するときは、 最初からOSPF設定を見るのではなく、 通信経路を一つずつ確認していきます。
IP・Mask・GW
GWへの疎通
Route・Next Hop
Return Route
- 送信元端末の設定を確認する IPアドレス、サブネットマスク、デフォルトゲートウェイを確認します。
- デフォルトゲートウェイまで通信できるか確認する ここで失敗する場合は、ルーティングより手前の問題を疑います。
- 各ルーターの経路表を確認する 宛先IPに対して実際にどの経路が選択されるか確認します。
- ネクストホップへ到達できるか確認する 経路表にネクストホップがあっても、 そのIPへ到達できなければ転送できません。
- 宛先側まで確認する tracerouteや各区間からのpingを利用して、 どこまで届いているか確認します。
- 戻り経路を確認する 宛先側から送信元ネットワークへの経路があるか確認します。
ルーティング障害では「どこまで届いたか」を確認することが重要です。
PC-A→R1、R1→R2、R2→PC-Bのように 通信を区間へ分けると、確認箇所を絞り込めます。
症状からルーティング障害を疑う
同一セグメントは通信できる
同じVLAN内では通信できるものの、 別ネットワークだけ通信できないケースです。
デフォルトゲートウェイやルーティングを優先的に確認します。
特定ネットワークだけ通信できない
一部の宛先だけ失敗する場合は、 特定プレフィックスの経路不足や 誤ったスタティックルートを疑います。
片方向だけ通信できない
行きの経路は存在していても、 宛先側に戻り経路がない可能性があります。
経路変更後から通信できない
ネクストホップ、プレフィックス長、 Administrative Distance、OSPF経路などを確認します。
STEP1：送信元端末の設定を確認する
最初に確認するのはルーターではなく、送信元端末です。
- IPアドレス
- サブネットマスク
- デフォルトゲートウェイ
- 対象インターフェースが正常か
特にサブネットマスクが間違っていると、 本来デフォルトゲートウェイへ渡すべき通信を 同一ネットワーク内の宛先と誤判断する場合があります。
Windowsの確認例
C:\> ipconfig
IPv4 アドレス . . . . . . . . . . : 192.168.10.10
サブネット マスク . . . . . . . . : 255.255.255.0
デフォルト ゲートウェイ . . . . . : 192.168.10.1Linuxの確認例
$ ip addr
$ ip route
default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.10「端末のIPアドレスは正しい」だけでは不十分です。
デフォルトゲートウェイとサブネットマスクも 必ずセットで確認します。
STEP2：デフォルトゲートウェイまで確認する
次に、送信元端末からデフォルトゲートウェイへpingします。
C:\> ping 192.168.10.1デフォルトゲートウェイに到達できない状態では、 その先のルーティングを確認しても原因の切り分けにはなりません。
ゲートウェイへpingできない場合
- 端末のIPアドレス・Mask・GW
- VLAN設定
- スイッチポート
- ARP
- ルーター側インターフェース
- 物理リンク
デフォルトゲートウェイまで正常なら、 少なくとも送信元LANからルーターまでの 基本的な通信は成立していると判断できます。
STEP3：ルーティングテーブルを確認する
デフォルトゲートウェイまで到達できたら、 ルーターが宛先をどこへ転送しようとしているか確認します。
R1# show ip route 192.168.20.20
Routing entry for 192.168.20.0/24
Known via "static"
Routing Descriptor Blocks:
* 10.0.12.2この例では、192.168.20.20宛ての通信は 192.168.20.0/24の経路に一致し、 ネクストホップ10.0.12.2へ転送されます。
確認する4項目
| 確認項目 | 確認する内容 |
|---|---|
| 宛先ネットワーク | 目的のIPアドレスを含む経路が存在するか |
| プレフィックス長 | より具体的な経路が存在しないか |
| ネクストホップ | 想定したルーターを向いているか |
| 出力インターフェース | 想定したリンクから転送されるか |
「経路がある」だけでは判断しない
O 192.168.20.0/24 via 10.0.12.2
S 192.168.20.128/25 via 10.0.13.2宛先が192.168.20.200の場合、 /24よりも具体的な 192.168.20.128/25 が使用されます。
ルーティングでは最長一致が優先されます。 障害調査では経路表を眺めるだけではなく、 実際の宛先IPアドレスを指定して確認する ことが重要です。
STEP4：ネクストホップへ到達できるか確認する
ルーティングテーブルに経路が存在していても、 ネクストホップまで通信できなければ パケットを先へ転送できません。
R1# ping 10.0.12.2ここで失敗する場合は、 宛先LANよりも先にR1とR2の間を確認します。
- R1・R2のインターフェース状態
- IPアドレスとサブネットマスク
- VLANやEtherChannel
- ARP
- ACLなどによる通信制御
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.10.1 YES manual up up
GigabitEthernet0/1 10.0.12.1 YES manual up upSTEP5：tracerouteで停止地点を確認する
複数のルーターを経由する場合は、 tracerouteを利用すると通信経路を確認できます。
Windows
C:\> tracert 192.168.20.20
1 <1 ms <1 ms <1 ms 192.168.10.1
2 2 ms 2 ms 1 ms 10.0.12.2
3 * * * 要求がタイムアウトしました。この結果だけでR2の障害と断定することはできませんが、 少なくとも確認対象をR2以降へ絞り込む材料になります。
Linux
$ traceroute 192.168.20.20Cisco
R1# traceroute 192.168.20.20tracerouteで「*」が表示されたからといって、 その機器が停止しているとは限りません。
ICMPなどへの応答を制限している機器もあるため、 pingや経路表など他の情報と組み合わせて判断します。
戻り経路を必ず確認する
ルーティング障害で特に見落としやすいのが 戻り経路です。
行きの経路だけ存在するケース
戻り：PC-B → PC-A ×
R1に192.168.20.0/24への経路があれば、 PC-Aから送信されたパケットはPC-Bへ到達できます。
しかし、R2に192.168.10.0/24への経路がなければ、 PC-Bからの応答をPC-Aへ戻せません。
R2# show ip route 192.168.10.10
% Network not in tablepingは往復して初めて成功します。
「宛先へパケットが届くこと」と 「通信全体が成功すること」を分けて考えましょう。
スタティックルート障害の確認
スタティックルートでは、 設定した宛先・プレフィックス・ネクストホップを確認します。
| 設定ミス | 発生しやすい症状 |
|---|---|
| 宛先ネットワークが間違っている | 必要な宛先に経路が一致しない |
| サブネットマスクが間違っている | 一部のIPアドレスだけ通信できない |
| ネクストホップが間違っている | 想定外の方向へ転送される |
| インターフェースがDown | 経路が利用できなくなる |
| 戻り側の経路がない | 片方向通信になる |
設定確認例
R1# show running-config | include ip route
ip route 192.168.20.0 255.255.255.0 10.0.12.2コンフィグだけでなく、 実際にルーティングテーブルへ登録されているかも確認します。
R1# show ip route 192.168.20.20OSPF障害の確認
OSPF環境では、 経路がないという結果だけを見て設定変更するのではなく、 どの段階で問題が発生しているか確認します。
- OSPFネイバーを確認する まず隣接ルーターとのネイバー状態を確認します。
- 対象ネットワークがOSPFへ参加しているか確認する 必要なインターフェースやネットワークが対象か確認します。
- 対向ルーターが経路を広告しているか確認する 経路を受信する側だけでなく、広告する側も確認します。
- 経路表へ登録されているか確認する 他のルーティング情報が優先されていないかも確認します。
ネイバー確認
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:36 10.0.12.2 GigabitEthernet0/1FULLであれば、この隣接ルーターとの OSPFネイバーは確立しています。
OSPF経路確認
R1# show ip route ospf
O 192.168.20.0/24 [110/2] via 10.0.12.2, GigabitEthernet0/1OSPF障害では「ネイバー」と「経路」を分けて確認します。
ネイバーがFULLでも、 必要なネットワークが広告されていなければ 目的の経路は学習できません。
ルーティング以外の障害を見分ける
経路が正常でも通信できないことがあります。
| 原因 | 代表的な症状 |
|---|---|
| ACL | 特定IP・プロトコルだけ通信できない |
| ファイアウォール | ポリシーやセッションによって通信が破棄される |
| NAT | アドレス変換や戻り通信に問題がある |
| VLAN | デフォルトゲートウェイまで到達できない |
| 端末側FW | 宛先まで到達していても応答しない |
| アプリケーション | pingは通るが特定サービスだけ利用できない |
「pingが通らない＝ルーティング障害」 と決めつけないことが重要です。
経路・ACL・ファイアウォール・NAT・ 宛先端末などを順番に切り分けます。
代表的な確認コマンド
Cisco IOS／IOS XE系
| コマンド | 確認内容 |
|---|---|
show ip interface brief |
インターフェース状態・IPアドレス |
show ip route |
ルーティングテーブル全体 |
show ip route <宛先IP> |
特定宛先に使用される経路 |
ping <IP> |
対象IPへの疎通 |
traceroute <IP> |
途中経路の確認 |
show arp |
ARPテーブル |
show ip ospf neighbor |
OSPFネイバー状態 |
show ip route ospf |
OSPFで学習した経路 |
show ip protocols |
ルーティングプロトコルの概要 |
Windows
ipconfig
route print
ping 192.168.20.20
tracert 192.168.20.20Linux
ip addr
ip route
ip route get 192.168.20.20
ping 192.168.20.20
traceroute 192.168.20.20実務では、コマンドを大量に実行するより、 「何を確認するために、そのコマンドを実行するのか」 を明確にすることが重要です。
調査結果をどう報告するか
障害対応では、原因を見つけるだけでなく、 どこまで正常だったかを根拠とともに説明する ことが重要です。
報告例
事象：
PC-A（192.168.10.10）から
サーバー（192.168.20.20）へ通信不可。
確認結果：
PC-Aからデフォルトゲートウェイへの疎通は正常。
R1には192.168.20.0/24への経路が存在し、
R1からR2への疎通も正常。
原因：
R2に192.168.10.0/24への戻り経路が存在せず、
応答パケットをPC-A側へ転送できない状態だった。
対応：
R2へ192.168.10.0/24宛ての経路を追加。
復旧確認：
PC-Aから192.168.20.20へのpingおよび
対象通信が正常であることを確認。
英語ドキュメントで見かける表現
| 英語 | 意味 |
|---|---|
| route is missing | 経路が存在しない |
| next hop is unreachable | ネクストホップへ到達できない |
| return path | 戻り経路 |
| asymmetric routing | 非対称ルーティング |
| route withdrawal | 経路広告の取り消し |
ルーティング障害でよくある勘違い
経路表にルートがあれば通信できる
経路が存在していても、 ネクストホップ、戻り経路、ACLなどに問題があれば 通信できません。
デフォルトルートがあれば十分
より具体的な経路が存在すれば、 最長一致によってそちらが選択されます。
OSPFがFULLなら正常
ネイバーがFULLでも、 必要なネットワークが広告されていなければ 経路は学習できません。
送信元側だけ確認すればよい
応答が必要な通信では、 宛先側から送信元への戻り経路も必要です。
理解度チェック
問題1．PCから別ネットワークへ通信できず、 デフォルトゲートウェイへのpingも失敗しています。 最初に優先して確認すべき場所はどこですか。
- 宛先側OSPF
- 送信元端末・LAN
- 戻り経路
- BGP
解答を見る
デフォルトゲートウェイへ到達できていないため、 端末設定、VLAN、ARP、ゲートウェイ側インターフェースなどを 先に確認します。
問題2．次の2つの経路が存在するとき、 192.168.20.200宛てにはどちらが使用されますか。
192.168.20.0/24 via 10.0.12.2
192.168.20.128/25 via 10.0.13.2解答を見る
192.168.20.200は両方に一致しますが、 /25のほうがより具体的なため最長一致で選択されます。
問題3．PC-AからPC-Bまでパケットは到達していますが、 応答がPC-Aまで戻りません。 優先して確認する項目は何ですか。
解答を見る
往路が正常でも、 復路の経路がなければ通信は成立しません。
問題4．OSPFネイバーがFULLなら、 必要なすべての経路が存在すると判断できますか。
解答を見る
ネイバーが確立していても、 必要なネットワークが広告されていなければ 目的の経路を学習できません。
問題5．経路表には目的の経路がありますが通信できません。 次に確認したい項目を3つ挙げてください。
解答例を見る
- 実際に選択されるネクストホップ
- ネクストホップへの到達性
- 宛先側からの戻り経路
実践演習：戻り経路がない障害を切り分ける
次のネットワークで、 PC-AからPC-Bへpingできない障害が発生しています。
演習用ネットワーク
PC-Aの設定
IP Address : 192.168.10.10
Mask : 255.255.255.0
Gateway : 192.168.10.1R1の確認結果
R1# show ip route 192.168.20.20
Routing entry for 192.168.20.0/24
Known via "static"
* 10.0.12.2
R1# ping 10.0.12.2
Success rate is 100 percentR2の確認結果
R2# show ip route 192.168.10.10
% Network not in table課題1．どこまで正常か整理してください
R1 → R2：
R2 → PC-Aへの戻り：
解答を見る
- PC-A → R1：端末設定上は正常と考えられる
- R1 → R2：ping成功のため到達可能
- R2 → PC-A：192.168.10.0/24への経路がない
課題2．最も可能性が高い原因を答えてください
解答を見る
R2に192.168.10.0/24への戻り経路が存在しないこと。
課題3．修正例を考えてください
解答例を見る
R2(config)# ip route 192.168.10.0 255.255.255.0 10.0.12.1実環境ではネットワーク設計に従い、 スタティックルートまたは動的ルーティングで 戻り経路を提供します。
課題4．障害報告を書いてください
確認結果：
原因：
対応：
復旧確認：
報告例を見る
事象： PC-AからPC-Bへの通信不可。
確認結果： R1には192.168.20.0/24への経路が存在し、 R1からR2への疎通も正常。 一方、R2には192.168.10.0/24への経路が存在しないことを確認。
原因： R2の戻り経路不足。
対応： R2へ192.168.10.0/24宛ての経路を追加。
復旧確認： PC-AからPC-Bへのpingおよび対象通信が正常であることを確認。
自分の言葉で説明する課題
「ルーティングテーブルには経路があるのに、 なぜ通信できないことがあるのですか？」 と後輩から質問されました。 1分程度で説明してください。
説明例を見る
ルーティングテーブルに経路があるということは、 ルーターが宛先へ送る方向を知っているという意味です。
しかし、そのネクストホップへ実際に到達できるとは限りません。 また、パケットが宛先へ届いても、 戻り経路がなければ応答は返ってきません。
そのため、経路の有無だけでなく、 ネクストホップへの到達性、宛先までの経路、 戻り経路まで順番に確認する必要があります。
まとめ
- ルーティング障害では、 送信元端末から順番に調査する
- 最初にデフォルトゲートウェイまで 到達できるか確認する
- 経路表では経路の有無だけでなく、 プレフィックス、ネクストホップ、出力先を確認する
- 実際の宛先IPに対し、 最長一致でどの経路が使われるか確認する
- 経路が存在していても、 ネクストホップへ到達できなければ転送できない
- tracerouteを使い、 どこまで通信が進んでいるか確認する
- 行きの経路だけでなく、 必ず戻り経路を確認する
- OSPFではネイバー状態と経路学習を分けて確認する
- 経路が正常でも、 ACL・FW・NAT・端末側に原因がある場合がある
ルーティング障害の基本は、 「どこから、どこまで、どの経路で届いているのか」を 一つずつ確認することです。
中級編では、 VLAN・STP・ルーティング・ネットワークサービス・ パケット解析を使い、 障害原因を根拠とともに説明できる状態を目指します。
コメント