Traceroute

このページのゴール

Tracerouteを、単に「途中のルータを表示するコマンド」として覚えるのではなく、TTLを段階的に変えた試行と各Hopから返るICMP応答を使って、どの範囲まで応答を観測できるかを判断する確認手段として使えるようにします。

特に重要なのは、

表示された最後のHop
=
障害地点

ではないことです。

Tracerouteは、

どこまで応答を観測できたか
どこから応答を観測できなくなったか
後続Hopは応答しているか
宛先まで到達したか

を整理し、追加確認すべき候補範囲を絞るために使います。

このページで学ぶこと

• TTLを段階的に増やしてHopを観測する仕組み
• TTLが尽きた途中ルータからのICMP Time Exceeded
• Cisco IOSの代表的なIPv4 UDP Tracerouteでの宛先到達
• 各Hopの応答が意味するもの
• *が示すタイムアウト
• *だけでは故障を証明できない理由
• *の後に後続Hopが応答する場合の読み方
• 往路のHop列から復路を断定できない理由
• Traceroute成功から証明できる範囲
• 継続的な応答喪失から追加確認範囲を絞る考え方

Tracerouteとは

Tracerouteは、送信元から宛先へ向かう経路上で、どのHopから応答を得られるかを観測するために使います。

代表的な確認イメージは、

送信元
  |
Hop 1
  |
Hop 2
  |
Hop 3
  |
宛先

です。

ただし、表示されたHop列そのものを「通信の全経路を完全に証明したもの」と考えてはいけません。

Tracerouteの中心はTTL

Tracerouteの基本原理はTTLです。

TTL = 1
TTL = 2
TTL = 3
TTL = 4
...

のように、試行ごとにTTLを段階的に増やします。

これによって、より遠いHopまで試行パケットを到達させます。

TTLとは

IPv4のTTLは、パケットがルータを通過するたびに減少する値です。

概念的には、

送信時 TTL 3
↓
ルータA 通過後 TTL 2
↓
ルータB 通過後 TTL 1
↓
ルータCでTTLが尽きる

のように扱います。

TTLが尽きたとき

途中ルータでTTLが尽きると、Tracerouteではその事実を利用してHopを観測します。

代表的には、

ICMP Time Exceeded

という応答を受信します。

TTL=1の試行

送信元から最初の試行を、

TTL = 1

で送ったとします。

最初のルータでTTLが尽きれば、そのルータからICMP Time Exceededを受信します。

結果として、

Hop 1

を観測できます。

TTL=2の試行

次は、

TTL = 2

として送ります。

最初のルータを通過し、次のルータでTTLが尽きれば、

Hop 2

を観測できます。

TTL=3の試行

さらに、

TTL = 3

として送ると、より遠いHopまで届きます。

途中の3番目のルータでTTLが尽きれば、そのルータからICMP Time Exceededを受信します。

TTLを段階的に増やす意味

目的は、

TTLを増やす
↓
試行パケットを1Hopずつ遠くへ進める
↓
途中Hopからの応答を観測する

ことです。

送信元アドレスやパケットサイズを1ずつ変えてHopを探す仕組みではありません。

1Hopずつ観測するイメージ

TTL 1
送信元 → R1
          ↑
     Time Exceeded

TTL 2
送信元 → R1 → R2
               ↑
          Time Exceeded

TTL 3
送信元 → R1 → R2 → R3
                    ↑
               Time Exceeded

この繰り返しで、経路上の応答Hopを順番に観測します。

ICMP Time Exceededの役割

途中Hopの観測では、

TTLが尽きた
↓
途中ルータがICMP Time Exceededを返す
↓
送信元がその応答を受信する
↓
そのHopを表示する

という流れが基本です。

Time Exceededを受信した意味

例：

TTL = 3

192.0.2.3から
ICMP Time Exceeded

を受信したなら、

その試行のTTLが192.0.2.3で尽き、
その応答を送信元が受信できた

と判断します。

Time Exceededは宛先到達ではない

途中HopからICMP Time Exceededを受信したことは、

最終宛先へ到達した

こととは別です。

その試行は途中でTTLが尽きています。

Cisco IOSでTracerouteを実行する

代表的な実行イメージ：

R1# traceroute 198.51.100.10

出力例：

Tracing the route to 198.51.100.10

  1 10.0.0.1 1 msec 1 msec 1 msec
  2 192.0.2.1 2 msec 2 msec 2 msec
  3 198.51.100.10 3 msec 3 msec 3 msec

この例では、Hop 1、Hop 2、最終宛先から応答を観測しています。

出力をHop単位で読む

1 10.0.0.1
2 192.0.2.1
3 198.51.100.10

なら、

Hop 1
→ 10.0.0.1から応答

Hop 2
→ 192.0.2.1から応答

Hop 3
→ 198.51.100.10から応答

と読みます。

表示されたIPは応答元

TracerouteでHopとしてIPアドレスが表示されたときは、

その試行に対する応答を
そのIPアドレスから受信した

という観測結果として扱います。

途中Hopを観測できる条件

途中Hopが表示されるには、概念的に、

試行パケットがそのHopまで届く
+
そのHopがICMP Time Exceededを返す
+
その応答が送信元まで戻る

必要があります。

応答が返る経路も必要

TracerouteのHop表示は、

送信方向だけ

で成立するわけではありません。

途中Hopから送信元へ応答が戻れなければ、そのHopを表示できない場合があります。

Cisco IOSの代表的なIPv4 UDP Traceroute

Cisco IOSの代表的なIPv4 UDP Tracerouteでは、途中HopのTTL満了に対して、

ICMP Time Exceeded

を利用します。

そして試行が宛先へ到達すると、宛先からの応答が完了判断の手掛かりになります。

宛先到達時の代表的な応答

代表的なIPv4 UDP Tracerouteでは、宛先側で未使用のUDPポートに到達したことにより、

ICMP Port Unreachable

などの応答を受信し、宛先到達を判断します。

途中Hopと宛先の応答を分ける

途中Hop：

TTLが尽きる
→ ICMP Time Exceeded

宛先：

試行が宛先まで到達
→ 宛先から完了判断に使える応答

という違いを整理します。

Echo Replyだけを待つものではない

Cisco IOSの代表的なIPv4 UDP Tracerouteでは、

宛先到達
=
通常のICMP Echo Replyだけで判断

とは考えません。

宛先からのICMP Port Unreachableなどが完了判断の手掛かりになります。

宛先が最終Hopとして応答した意味

宛先が最終Hopとして表示された場合、

Tracerouteの試行が宛先まで到達し、
宛先から完了判断に使える応答を受信した

と判断できます。

宛先応答から言い過ぎない

宛先が応答したからといって、

Web正常
SSH正常
DNS正常
全アプリケーション正常

まで証明したわけではありません。

Tracerouteとしての到達性観測と、アプリケーション正常性は分けます。

Hop応答の証拠範囲

Hopが表示された場合、直接言えるのは、

その試行条件で
そのHopから応答を受信した

ことです。

そのルータ上のすべての機能が正常という意味ではありません。

Hopが応答したことと転送正常を分ける

ICMP Time Exceededを返せることと、

すべての転送が完全に正常

は同じではありません。

観測できた事実だけを使います。

*とは

Traceroute出力で、

*

が表示されることがあります。

*は、その試行についてタイムアウトまで期待した応答を受信できなかったことを示します。

*は故障確定ではない

最も重要な誤読防止です。

*
=
そのルータが必ずdown

ではありません。

*から直接言えること

直接言えるのは、

その試行では
タイムアウトまで期待した応答を受信しなかった

ことです。

原因はまだ未確定です。

*の原因は一意ではない

考えられる方向は複数あります。

そのHopが応答を返さない
応答が制限されている
フィルタリングされている
応答の復路に問題がある
一時的に応答を受信できなかった

したがって、*だけで原因を決めません。

3回のうち1回だけ*

例：

2 192.0.2.1 2 msec * 3 msec

なら、

3回の試行のうち
1回は期待した応答を受信しなかった

と読みます。

1回の*でHop故障と決めない

1回だけタイムアウトした場合、

ルータ故障確定
リンク断確定
ルーティングループ確定

とは判断しません。

まず個々の試行結果として扱います。

同じHopが* * *

例：

3 * * *

この場合、

そのHop番号に対する複数試行で
期待した応答を受信できなかった

と読みます。

それでも、ルータ故障とはまだ確定しません。

*の後に後続Hopが応答する場合

重要なパターンです。

1 10.0.0.1
2 *
3 192.0.2.1
4 198.51.100.10

この場合、Hop 2は*ですが、Hop 3と宛先が応答しています。

後続Hop応答から分かること

Hop 2が*でもHop 3が応答したなら、

試行パケットはHop 2より先へ進んだ可能性が高い

と判断できます。

したがって、

Hop 2が転送停止地点

とは断定しません。

応答しないことと転送しないことは別

あるルータが、

TTL満了へのICMP応答を返さない

一方で、

通常の転送は続ける

ことはあり得ます。

そのため、後続Hopを見ることが重要です。

Hop 2が*で宛先まで応答する例

1 10.0.0.1
2 *
3 192.0.2.1
4 198.51.100.10

この結果から、

Hop 2の応答は観測できなかった
しかし後続Hopと宛先の応答は観測できた

と整理します。

*を通信停止地点と誤認しない

悪い判断：

Hop 2が*
↓
Hop 2で通信停止確定

良い判断：

Hop 2の応答なし
↓
後続Hopを確認
↓
後続Hopが応答するなら
Hop 2を停止地点とは確定しない

です。

継続して*になる場合

例：

1 10.0.0.1
2 192.0.2.1
3 203.0.113.1
4 203.0.113.2
5 *
6 *
7 *
8 *

この場合、Hop 4までは応答を観測し、それ以降は継続して応答を観測できていません。

継続的な応答喪失の読み方

直接言えること：

Hop 4までは応答あり
Hop 5以降は期待した応答なし

です。

ここから、Hop 4より先の範囲を追加確認候補として絞れます。

最後に応答したHopを原因と決めない

例：

Hop 4までは応答
Hop 5以降は*

でも、

Hop 4故障確定

とはしません。

最後に応答したHopは、単に最後に応答を観測できた地点です。

最初に*になったHopを原因と決めない

同様に、

Hop 5が最初の*
↓
Hop 5故障確定

でもありません。

Hop 5から応答を受信できなかったという事実に留めます。

候補範囲として扱う

継続的な応答喪失では、

最後に応答したHop
↓
最初に応答を失ったHop
↓
その先の経路

を追加確認範囲として扱います。

候補範囲と原因確定を分ける

Tracerouteの役割は、

原因を一意に証明

ではなく、

追加確認する範囲を絞る

ことです。

追加確認範囲の例

Hop 1 成功
Hop 2 成功
Hop 3 成功
Hop 4 成功
Hop 5以降 *

なら、

Hop 4以降の経路
Hop 5付近
Hop 5より先

を候補範囲として扱います。

候補範囲で確認するもの

Tracerouteの結果だけで止めず、候補範囲で、

インターフェース状態
経路情報
フィルタリング
装置間の到達性
必要に応じたパケットレベルの観測

などを追加確認します。

Tracerouteは候補範囲を作る道具

最終判断の流れは、

Traceroute
↓
応答範囲を把握
↓
候補範囲を絞る
↓
別の確認情報で検証
↓
原因判断

です。

往路と復路を分ける

Tracerouteで表示されるHop列は、主に送信方向の試行によって観測されたHopです。

ここから、

応答が戻る経路も完全に同じ

とは断定できません。

非対称経路を考える

ネットワークでは、

往路
A → B → C → 宛先

復路
宛先 → D → E → A

のように、往路と復路が異なることがあります。

表示Hop列だけで復路は証明できない

Tracerouteが、

A → B → C → 宛先

と見えても、

復路も
宛先 → C → B → A

であるとは限りません。

Hop応答にも復路がある

途中Hopから返るICMP Time Exceededにも、送信元へ戻る経路があります。

その応答経路が、試行パケットの往路と同一とは限りません。

*と復路の関係

途中Hopが試行を受け取っていても、そのHopからの応答が送信元へ戻らなければ、

*

として見える可能性があります。

したがって、*だけで往路側の故障と断定しません。

Traceroute成功と復路完全一致を分ける

宛先までTracerouteが完走しても、

往路と復路が完全に同じ

とは証明できません。

別地点の観測と両立する

送信方向のTracerouteで、

A → B → C → 宛先

と観測し、別地点のパケット観測で戻り方向が、

宛先 → D → E → A

だったとしても、両方の観測は両立し得ます。

Tracerouteの経路範囲

Tracerouteから直接分かるのは、

そのTraceroute試行で
どのHopから応答を受信したか

です。

アプリケーション通信の全経路ではない

Tracerouteが完走しても、

Web通信の完全な双方向経路

まで証明したわけではありません。

Traceroute成功とサービス正常を分ける

状況：

Traceroute
→ 宛先まで完走

Web
→ 通信失敗

は起こり得ます。

完走後も追加確認が必要な場合

Traceroute完走後もアプリケーション通信が失敗するなら、

サービス状態
ポート到達性
ポリシー
フィルタリング
アプリケーション側条件

など、Tracerouteの証拠範囲外を追加確認します。

完走は「すべて正常」ではない

悪い判断：

Traceroute完走
↓
ネットワークもアプリケーションも全正常

良い判断：

Traceroute試行は宛先まで到達
↓
この試験の到達性は確認
↓
未確認の通信条件は別途確認

です。

途中Hopがすべて応答しても限界がある

全Hopが表示されても、

全ACLが存在しない
すべてのポートが許可
すべてのアプリケーションが正常

とは言えません。

Traceroute失敗も原因一意ではない

宛先まで完走しない場合でも、

宛先停止
経路不備
応答制限
フィルタリング
復路問題

など複数の可能性があります。

最後の応答Hopを記録する

継続的に*となる場合は、

最後に応答したHop

を記録します。

例：

4 203.0.113.2
5 *
6 *
7 *

なら、最後に応答したのはHop 4です。

最初の継続タイムアウトを記録する

同時に、

最初に継続タイムアウトとなったHop

も記録します。

この例ではHop 5です。

範囲で記録する

原因を決めず、

Hop 4までは応答
Hop 5以降は継続タイムアウト

と記録します。

単発*と継続*を分ける

単発：

1 応答
2 *
3 応答
4 宛先応答

継続：

1 応答
2 応答
3 応答
4 *
5 *
6 *

では、扱いが異なります。

単発*では後続Hopを優先確認

単発*の後に後続Hopが応答する場合、

そのHopの応答を受信できなかった

ことに注目し、転送停止地点とはしません。

継続*では候補範囲を絞る

後続Hopも宛先も応答しない状態が続くなら、

最後に応答したHopより先

を追加確認範囲として扱いやすくなります。

RTT値だけで故障を決めない

TracerouteではHopごとに応答時間が表示されることがあります。

例：

1 10.0.0.1 1 msec 1 msec 1 msec
2 192.0.2.1 20 msec 21 msec 19 msec

この値だけで根本原因を確定しません。

応答時間は観測値として扱う

応答時間が変化していても、

そのHopが必ず障害

とは限りません。

このページでは、主にHop応答の有無と範囲を判断軸にします。

実行結果を表に整理する

例：

この場合、Hop 2を通信停止地点とは判断しません。

継続タイムアウトを表に整理する

原因ではなく、候補範囲として整理します。

Tracerouteの切り分けフロー

Traceroute実行
↓
宛先まで完走したか
↓
各Hopの応答を確認
↓
単発*か継続*か
↓
後続Hopが応答するか
↓
最後に応答したHopを確認
↓
追加確認範囲を決める
↓
別の確認情報で検証

宛先まで完走した場合

1 応答
2 応答
3 応答
4 宛先応答

なら、

Traceroute試行は宛先まで到達した

と判断します。

アプリケーション正常性は別です。

宛先前で継続タイムアウトする場合

1 応答
2 応答
3 応答
4 *
5 *
6 *

なら、

Hop 3までは応答を観測
Hop 4以降は応答を観測できない

と整理します。

途中だけ*の場合

1 応答
2 *
3 応答
4 宛先応答

なら、

Hop 2の応答は観測できない
後続Hopと宛先は応答

と整理します。

3試行中1試行だけ*の場合

2 192.0.2.1 2 msec * 2 msec

なら、

同じHopの3試行中1試行だけタイムアウト

です。

ルータ故障とは断定しません。

Hopが複数アドレスで表示される場合

複数試行で異なる応答元が観測される場合でも、

観測された応答元

として扱います。

表示だけで内部構成や根本原因を決めません。

TracerouteをPingの代替と考えない

PingとTracerouteは確認目的が異なります。

Ping
→ 指定宛先との到達性を確認

Traceroute
→ 経路上の応答Hopと範囲を観測

という違いで整理します。

Ping成功でもTracerouteに*はあり得る

宛先へのPingが成功していても、途中HopがTraceroute応答を返さなければ、

*

が表示される場合があります。

したがって、Ping成功と途中Hopの*は矛盾しません。

Traceroute完走でも途中*はあり得る

例：

1 10.0.0.1
2 *
3 192.0.2.1
4 198.51.100.10

宛先まで完走しているため、途中の*だけで経路断とは判断しません。

Traceroute未完走でも最後のHopを原因と決めない

例：

1 10.0.0.1
2 192.0.2.1
3 203.0.113.1
4 *
5 *

最後に応答した203.0.113.1が原因とは限りません。

最後の応答Hopより先を見る

継続タイムアウト時は、

最後に応答したHopの先

を調べるための候補範囲を作ります。

最後の応答Hopそのものだけに絞りません。

応答しないHopより前も必要に応じて確認する

候補範囲は、

最後に応答した装置
その次の区間
最初に応答を失った付近

を含めて考えます。

経路情報との相関

Tracerouteで候補範囲を絞ったら、

該当装置の経路情報
次Hop
出口インターフェース

などを確認し、観測結果と整合するか検証します。

インターフェース状態との相関

候補範囲では、

インターフェースがupか
エラーが増えていないか
リンク状態に変化がないか

などを確認します。

フィルタリングとの相関

*がある場合、

応答だけが制限されている

可能性も考えます。

そのため、転送停止と応答制限を分けて確認します。

別方向の確認との相関

Tracerouteは往路側のHop観測が中心です。

復路に疑いがある場合は、別地点や別方向から得た確認情報と合わせて判断します。

観測事実と仮説を分ける

例：

観測事実
→ Hop 4までは応答
→ Hop 5以降は継続タイムアウト

仮説
→ Hop 4より先の経路に問題がある可能性
→ 応答制限の可能性
→ 復路問題の可能性

未確定
→ 根本原因

この形で整理します。

「最後の応答Hop」と「障害Hop」を分ける

最後の応答Hop

は観測事実です。

障害Hop

は追加確認後に判断するものです。

両者を同一視しません。

「最初の*」と「障害Hop」を分ける

最初の*

も観測事実です。

それだけでは、

障害地点

を証明できません。

「宛先応答」と「アプリ正常」を分ける

宛先からTracerouteの完了応答を受信したことは、

Traceroute試行が宛先へ到達

した証拠です。

アプリケーション正常性とは別です。

「Hop応答」と「全転送正常」を分ける

あるHopからICMP Time Exceededを受信しても、

その装置のすべての転送が正常

まで証明しません。

「往路表示」と「復路同一」を分ける

TracerouteのHop列が見えても、

復路も同じHop列

とは断定しません。

実務での記録例

実行元: R1
宛先: 198.51.100.10

Hop 1: 10.0.0.1 応答
Hop 2: 192.0.2.1 応答
Hop 3: *
Hop 4: 203.0.113.1 応答
Hop 5: 198.51.100.10 応答

判断:
Hop 3の応答は観測できないが、
後続Hopと宛先は応答しているため、
Hop 3を転送停止地点とは断定しない。

このように結果と判断を分けて残します。

継続タイムアウト時の記録例

Hop 1: 応答
Hop 2: 応答
Hop 3: 応答
Hop 4: 応答
Hop 5: *
Hop 6: *
Hop 7: *

判断:
Hop 4までは応答を観測。
Hop 5以降で継続して応答を観測できない。
Hop 4より先を追加確認候補範囲とする。

宛先到達時の記録例

Hop 1: 応答
Hop 2: 応答
Hop 3: 宛先応答

判断:
Traceroute試行は宛先まで到達。
アプリケーション通信の正常性は別途確認。

途中*後に宛先応答する記録例

Hop 1: 応答
Hop 2: *
Hop 3: 応答
Hop 4: 宛先応答

判断:
Hop 2から期待応答を受信できなかった。
後続Hopが応答しているため、
Hop 2を転送停止地点とはしない。

問題での判断パターン

パターン1：Hopを観測する基本原理

TTLを段階的に増やす

と判断します。

パターン2：TTLを1、2、3と増やす目的

より遠いHopまで試行パケットを到達させる

ためです。

パターン3：途中ルータでTTLが尽きる

代表的な応答は、

ICMP Time Exceeded

です。

パターン4：TTL=3で192.0.2.3が表示

TTLが192.0.2.3で尽き、
その試行へのICMP Time Exceededを受信した

と判断します。

パターン5：Cisco IOSの代表的なIPv4 UDP Tracerouteの宛先到達

宛先からの、

ICMP Port Unreachable

などが完了判断の手掛かりになります。

パターン6：宛先が最終Hopとして応答

直接言えるのは、

Traceroute試行が宛先まで到達し、
宛先から応答を受信した

ことです。

パターン7：*の意味

その試行でタイムアウトまで期待応答を受信しなかった

です。

パターン8：3試行中1試行だけ*

その1試行の応答を受信できなかった

と判断します。

パターン9：Hop 3が*

Hop 3故障

とは断定せず、後続Hopと追加確認情報を見ます。

パターン10：Hop 2が*、Hop 3と宛先が応答

Hop 2は転送している可能性があり、
Traceroute用の応答だけを観測できなかった可能性

を考えます。

パターン11：途中Hopが*でも後続Hopが応答

そのHopがTTL満了への応答を返さない
または応答を受信できない一方、
試行パケットは先へ転送されている可能性

があります。

パターン12：往路Hop列から復路を断定できるか

断定できない

と判断します。

往路と復路は異なる可能性があります。

パターン13：往路と別地点の戻り方向観測が異なる

非対称経路なら両方の観測は両立し得る

と判断します。

パターン14：Traceroute成功で証明できないもの

アプリケーション通信の完全な双方向経路

は証明できません。

パターン15：Web通信障害でTraceroute完走

Tracerouteの証拠範囲を超えるため、
サービスやポリシーなどを追加確認

します。

パターン16：Hop 1〜4応答、以降宛先まで継続タイムアウト

Hop 4より先を追加確認候補範囲として扱う

のであり、Hop 4故障と確定しません。

パターン17：候補範囲を絞った後

インターフェース
経路
フィルタリング
パケットレベルの観測

など別の確認情報で検証します。

パターン18：Tracerouteの利用目的

経路上で応答を得られる範囲を観測し、
追加確認範囲を絞る

ことです。

よくある誤り

*をルータdownと決める

*はその試行で期待応答を受信できなかったことを示します。

故障原因までは証明しません。

最後に応答したHopを原因と決める

最後に応答したHopは、最後に応答を観測できた地点です。

原因地点とは限りません。

最初に*になったHopを原因と決める

最初の*も観測結果です。

原因確定には追加確認が必要です。

後続Hopを見ない

途中Hopが*でも、後続Hopが応答すれば転送停止地点とは断定できません。

宛先到達でアプリケーション正常と決める

Traceroute試行の宛先到達とアプリケーション正常性は別です。

往路と復路を同一と決める

非対称経路があり得るため、往路のHop列だけで復路を証明できません。

ICMP Time Exceededを宛先応答と混同する

途中HopのTTL満了応答と、宛先到達時の完了判断は分けます。

Port Unreachableを途中Hopの通常応答と混同する

代表的なIPv4 UDP Tracerouteでは、途中HopはICMP Time Exceeded、宛先到達ではICMP Port Unreachableなどを手掛かりにします。

Tracerouteだけで根本原因を確定する

Tracerouteは候補範囲を絞るために使い、別の確認情報で検証します。

切り分けの基本フロー

Tracerouteを実行
↓
宛先まで応答したか
↓
各Hopの応答を確認
↓
*の位置を確認
↓
後続Hopが応答するか確認
↓
単発*か継続*かを分ける
↓
最後に応答したHopを確認
↓
追加確認範囲を絞る
↓
別の確認情報で仮説を検証

運用確認で残す情報

実行時刻
実行元
宛先IP
Hop番号
応答元IP
各試行の応答有無
*の位置
後続Hopの応答有無
最後に応答したHop
宛先到達有無

を残すと、結果を比較しやすくなります。

観測事実を先に書く

例：

Hop 1〜4は応答。
Hop 5以降は宛先まで継続タイムアウト。

ここまでは観測事実です。

その後で、

Hop 4より先を追加確認候補とする。

と判断します。

原因仮説は別に書く

例：

仮説:
Hop 4より先の経路不備
フィルタリング
応答制限
復路問題

と分けます。

Tracerouteで分かること

• TTLを段階的に増やした試行で応答を得たHop
• 途中HopからのICMP Time Exceeded
• 宛先まで試行が到達したか
• どのHop番号で*が発生したか
• *の後に後続Hopが応答するか
• どこまで継続して応答を観測できたか

Tracerouteだけでは分からないこと

• *の根本原因
• 最後の応答Hopが障害地点か
• 往路と復路が完全に同じか
• アプリケーション通信の完全な双方向経路
• サービス正常性
• すべてのフィルタリング条件

最終判断の型

1. TTLの仕組みを確認
2. 途中HopのTime Exceededを読む
3. 宛先到達を確認
4. *をタイムアウトとして読む
5. *の後のHopを確認
6. 単発か継続かを分ける
7. 往路と復路を分ける
8. 最後の応答Hopを原因と決めない
9. 候補範囲を絞る
10. 別の確認情報で検証する

まとめ

Tracerouteは、TTLを段階的に増やした試行を送り、途中Hopからの、

ICMP Time Exceeded

などを利用して経路上の応答Hopを観測します。

Cisco IOSの代表的なIPv4 UDP Tracerouteでは、宛先到達時に、

ICMP Port Unreachable

などの応答が完了判断の手掛かりになります。

*は、

その試行でタイムアウトまで期待応答を受信しなかった

ことを示しますが、

ルータ故障
リンク断
転送停止

を単独で証明しません。

特に、

Hop 2 *
Hop 3 応答
宛先 応答

のように後続Hopが応答する場合、Hop 2を転送停止地点とは断定しません。

また、表示された往路Hop列から、

復路も完全に同じ

とは判断できません。

継続的に応答を失った場合は、

最後に応答したHop
+
その先の範囲

を追加確認候補として扱い、別の確認情報で検証します。

Tracerouteの役割は、障害地点を一意に決めることではなく、応答を観測できる経路範囲を把握して次の確認範囲を絞ることです。