tracertコマンドでネットワークの経路を調査する【Windows 10トラブル対策】：Tech TIPS
Windows PCでLANやインターネット上のサイトに接続できなくなってしまった場合、tracertコマンドを使うと、その原因がネットワーク経路のどこにあるのか、その手がかりを探索できる。tracertの仕組みから使い方、実行例までを解説する。
対象OS：Windows 10
突然、LAN上あるいはインターネット上のサイトにつながらなくなったり、急激に遅くなったりした経験は誰しもあることだろう。
もし、その原因が、ローカルのWindows PCから対象サイトまでの間のネットワーク（通信の経路）にあるとしたら、Windows OS標準の「tracert」コマンドが原因究明のために利用できる。
本Tech TIPSでは、tracertコマンドの基本的な仕組みと使い方について説明する。普段Windows PCを使っていて、かつネットワークのトラブルシューティングも担当しているなら、tracertコマンドの使い方を知っていて損はないだろう。
tracertコマンドとは？
TCP/IPネットワークにおける基本的なトラブルシューティングツールとして「pingコマンド」がある。このコマンドは、指定された宛先ホストに対して、ICMPプロトコル（TCP/IPプロトコルにおける、基本的な制御用プロトコル）を送信し、その応答状態を表示させるコマンドである。pingコマンドの使い方については、Tech TIPS「『ping』コマンドでネットワークトラブルの原因を調査する」を参照していただきたい。
このpingと同様の目的に使われるコマンドとして、Windows OSには「tracert」というコマンドが標準装備されている（UNIXやLinuxなどでは「traceroute」という名称になっている）。tracertコマンドも、pingと同じくICMPプロトコルのEcho要求を送信することにより、指定された宛先への到達可能性を調査する（UNIX版ではICMPプロトコル以外にUDPプロトコルも使用できる）。しかし、ルーティングの途中で経由したホスト（ルータ）を逐一表示するという点が異なる。
tracertでは、TCP/IPプロトコルにおけるTTL（Time To Live）を使って途中のルータのIPアドレスを求めている。TTLとは、IPヘッダ中に含まれる特別なフィールドであり、IPパケットが通過可能なルータの最大数を表している。ルータがIPパケットをルーティングする場合、ルータを1つ通過するたびにこのTTL値が減らされ、0になるとIPパケットは廃棄される（詳細は「基礎から学ぶWindowsネットワーク第10回― 2．IPフラグメンテーション」参照）。
このTTLの値はデフォルトでは64あるいは128、255など、十分大きな値にセットされていることが多い。しかし、tracertではわざと小さな値にしてルーティングの途中でTTLが0になるようにしている。
TTLが0になるとIPパケットが廃棄されると同時に、そのルータから送信元のIPアドレスに対して、「宛先不達（Destination unreachable）」というICMPのエラーパケットが送り返されてくる。tracertではこのICMPパケットを受信することにより、どこのルータでTTLが0になったか、つまりどこまでIPパケットが届いていたかを知ることができる。TTLの値を1から順番に1つずつ大きくしてIPパケットを送信することにより、目的のホストまでの経路中に存在するルータを調べることが可能になる。
組織内のネットワークの場合、通過するルータの数もせいぜい数段くらいしかないので、tracertの出番はあまり多くない。だがインターネット上のホストと通信する場合は、経路の途中でトラブルが発生し、通信ができなくなることもしばしばである。
そのような場合には、実際に経路が途中で途絶えているのか、それとも単にネットワークが混雑して通信が滞っているのかなどを見極めるためにtracertを活用できる。
tracertコマンドの使い方
tracertコマンドの使い方は、以下のように、引数を付けずにコマンドを実行すると表示される。
pingコマンドと同様に、引数には宛先となるホスト名（IPアドレスかFQDN）を指定する。
| オプション名 | オプションの概要 |
|---|---|
| -d | 通過したルータのIPアドレスからホスト名（FQDN）を逆引きしない |
| -h ＜ホップ数＞ | 経路の途中で通過できるルータの最大数を指定。デフォルトは30 |
| -j ＜IPアドレスのリスト＞ | （IPv4のみ）通過するルータを強制的に指定（ルーズソースルーティング） |
| -w ＜待ち時間＞ | ルータからのICMPパケットを受信するまでの待ち時間（タイムアウト値）を指定。単位はミリ秒。デフォルトは4秒 |
| -4 | IPv4による経路探索を強制 |
| -6 | IPv6による経路探索を強制 |
| -R | （IPv6のみ）IPv6の拡張ヘッダ（ルーティングヘッダ）を使ってローカルホストへEcho要求メッセージを送信する。復路のルートのテストに利用 |
| -S ＜ソースアドレス＞ | （IPv6のみ）Echo要求メッセージで使用する送信元アドレスを指定 |
| tracertコマンドのオプション一覧 オプションに含まれるハイフン「-」は、スラッシュ「/」でもよい。 | |
以下では主要なオプションについて説明する。
●「-d」オプション： 逆引きを止めて探索結果をもっと早く表示
「-d」オプションは、IPアドレスから名前（FQDN名）を求めないようにするためのオプションである。
デフォルトでは、通過したルータのIPアドレスから、DNSを使ってFQDN名を求めて表示するようになっている。だが、この名前解決のために幾らか時間がかかるので、-dオプションによってこれを省略できる。
またFQDN名を割り当てられていないIPアドレス（ルータ）も数多く存在するので、このような場合にも-dオプションを利用すると、結果を素早く表示させることができる。
●「-h」オプション： 多数のルータを経由している場合に利用
「-h ＜ホップ数＞」オプションは、tracertで設定する最大TTL数を指定するために利用される。
デフォルトでは「30」となっているので、最大では経路途中で通過できるルータ数は最大でも30台までに制約される。経路途中に30台以上ルータが存在する場合（30ホップよりも遠くにある場合）、tracertは処理を打ち切ってしまうので、このオプションを利用して、より大きな値を指定する必要がある。
●「-j」オプション： 経由するルータを強制するのに利用
「-j ＜IPアドレスのリスト＞」は、通過する経路（ルータ）を明示的に指定する「ソースルーティング（Source Routing）」を適用する場合に利用する。
デフォルトでは、ルータの持つルーティングテーブルに従ってルーティング処理が行われる。一方、「ソースルーティング」とは、ルーティングの途中で使用するルータを強制的に指定するルーティング方法であり、あらかじめIPパケットの中に、通過すべきルータの一覧リスト（最大で9台まで指定可能）を埋め込んでおく手法である。
「ソースルーティング」には2種類がある。「ストリクトソースルーティング（厳密なソースルーティング）」は、指定されたルータ「だけ」を通過するようにルーティングする方法である。「ルーズソースルーティング」は、指定されたルータ「以外も」利用してルーティングできる。
このうち、tracertコマンドではルーズソースルーティングだけが指定できる。ちなみにpingコマンドではこの両方のソースルーティングが利用できる。
なお、ソースルーティングはセキュリティ対策のため、ルータやOSではデフォルトで無効化（禁止）されていることが多い。そのため実際には、-jオプションを指定すると、「要求がタイムアウトしました。」と表示されて経路探索ができないことがよくある。
●「-w」オプション： 遅いネットワークでタイムアウト防止に利用
「-w ＜待ち時間＞」オプションは、ルータからのICMPパケットを受信するまでの待ち時間を指定する。
デフォルトの待ち時間は「4000（＝4秒。1/1000秒単位で指定する）」である。応答が遅いネットワークなどでは、この時間を超えてもパケットを受信できず、応答時間の代わりに「*」が表示されることがよくある。
そのような場合は、「4000」より大きな数値を-wオプションで指定することで、待ち時間を延ばせばよい。
●「-4」「-6」オプション： IPv4／IPv6を特定して経路探索
「-4」オプションはIPv4で、「-6」オプションはIPv6でそれぞれ経路探索することを強制するオプションだ。
ローカルホストでIPv4とIPv6の両方とも使える（デュアルスタック構成の）場合、デフォルトでどちらのプロトコルスタックが利用されるかは、ネットワークの環境や状況によって異なる。もし意図せぬプロトコルスタックで検索されてしまった場合は、どちらかのオプションを指定することでプロトコルスタックを強制的に選択できる。
tracertコマンドの使用例
●ローカルのホストへ向けたtracertコマンドの実行例
まずは、LAN上のホスト（つまりネットワーク的に近くにあるホスト）へのtracertを実行してみよう。
この場合は、目的のホスト（10.10.2.201）に到達するまでに、途中に1台のルータだけしか存在していない。
「<1 ms」という値が表示されているのは、そのホストからの応答が「1msec（1ミリ秒）」以下であったということを表している。3つ表示されているのは、3回パケットを送って、3回とも応答が1ミリ秒以下であったということである。3回実行するのは、ネットワークの混雑などの影響を見るためであり、ばらつきが大きいようであればネットワークがより混雑していると判断できる。
1行目ではホスト名が表示されている一方で、2行目ではホスト名は表示されていない。これは、2行目のホストでIPアドレスからFQDN名への逆引きができなかったからである。
●インターネット上のホスト（サイト）へ向けたtracertの実行例
今度はインターネット上のホストへtracertを実行してみよう。
最初の6行ほどは、応答値が数ミリ秒に治まっている。これは国内のインターネット回線を経由しているからである。
一方、7行目から急に応答値が30ミリ秒以上になっている。ここから先は海外のルータからの応答なので、海底ケーブルを経由する分だけ遅くなっている。3つの応答はそれぞれ似たような値になっているので、ネットワークはあまり混雑していないように見受けられる。
13行目から先は、すべて「* * * 要求がタイムアウトしました。」しか表示されていない。これは、そのルータからの応答がなかったということを示している。ルータやファイアウォールによっては、このようにtracertに対して応答を返さないように設定されていることも多く、その場合はこのように表示される。
●ルーティングが失敗する場合のtracertの例
途中でルーティングが行えなくなった場合は、次のようになる。
ここでは「172.16.1.2」というプライベートIPアドレスに対してtracertを実行してみた。プライベートIPアドレスなので、インターネットへ向けてtracertを実行しても、途中で必ずルーティングが失敗することになる。
途中で有効な経路がなくなったような場合は、このように最後のルータから「＜ルータのIPアドレス＞ レポート: 宛先ホストに到達できません。」という応答が戻ってくることがある。これらの情報により、途中のルータのルーティングテーブルの設定ミスや経路の途絶などが分かる。
■この記事と関連性の高い別の記事
■更新履歴
【2021/08/18】最新の情報を反映しました。Windows 10のスクリーンショットを追加しました。
【2003/05/03】初版公開（対象はWindows 9x／Windows Me／Windows 2000）。
Copyright© Digital Advantage Corp. All Rights Reserved.