この文書は、ネットワークパス情報、特にTracerouteを分析し、ネットワークパスがユーザーエクスペリエンスに重大な影響を与えているかどうかを判断しようとしているすべての人を対象としています。
Tracerouteに基づくネットワーク診断は、誤検出率が高いという問題がある。これは主に、Traceroute レポートのメトリクスの誤解が原因です。 この文書は、Tracerouteの結果を正確に解釈し、誤診を減らすためのものです。
Tracerouteとは何ですか？
Tracerouteは、インターネット上の問題をトラブルシューティングするための主要なツールです。これはコマンドラインユーティリティで、IPアドレスまたはホスト名を指定すると、送信元と宛先間のルーターホップのリスト、遅延、パケット損失、ルーターの詳細などの関連メトリックを表示します。
Tracerouteの概要：
- 送信元デバイス（SRC）は、TTLが1のプローブパケットを宛先デバイス（DST）に向けて送信します。
- ルーターがホップするたびに、パケットのTTLが1ずつ減少します。
- TTLが0になるとパケットは破棄され、ルーターは元のプローブパケットをペイロードとして含む「ICMP TTL Exceeded」パケットをSRCに送信します。
- SRCはこのICMPメッセージを受信し、Tracerouteの「ホップ」を表示します。
- ステップ1からこれを繰り返し、DSTホストがプローブパケットを受信するまで、TTL値を毎回1ずつ増やします。
- DSTホストがプローブパケットを受信すると、「ICMP宛先到達不能」を返します。
- SRCは「ICMP宛先到達不能」を受信すると、Tracerouteを停止します。
- DSTがプローブパケットを受信しない場合、またはプローブパケットに応答しない場合、tracerouteは通常、一定回数の試行失敗後にタイムアウトします。
出力例（Linux）：
Traceroute to www.ntt.net (130.94.58.116), 64 hops max, 52 byte packets 1 ge0-34.aggrFZ155-2.ord6.us.scnet.net (204.93.176.73) 4.558 ms 2.030 ms 2.730 ms 2 ge9-47.ar1.ord6.us.scnet.net (75.102.0.65) 0.405 ms 0.297 ms 0.265 ms 3 61.po4.ar1.ord1.us.scnet.net (75.102.3.225) 1.305 ms 1.249 ms 1.232 ms 4 ae0-81.cr1.ord1.us.nlayer.net (69.31.111.1) 1.135 ms 59.441 ms 1.144 ms 5 ae1.ar2.ord1.us.nlayer.net (69.31.111.146) 1.419 ms 2.249 ms 1.452 ms 6 as2914.xe-6-0-3.ar2.ord1.us.nlayer.net (69.31.111.233) 1.450 ms as2914.xe-6-0-2.ar1.ord1.us.nlayer.net (69.31.111.209) 1.608 ms as2914.xe-6-0-3.ar2.ord1.us.nlayer.net (69.31.111.233) 1.497 ms 7 ae-7.r21.chcgil09.us.bb.gin.ntt.net (129.250.4.201) 9.476 ms ae-6.r21.chcgil09.us.bb.gin.ntt.net (129.250.2.26) 1.389 ms 9.325 ms 8 ae-5.r20.snjsca04.us.bb.gin.ntt.net (129.250.3.107) 52.695 ms 54.304 ms 57.892 ms 9 ae-1.r06.snjsca04.us.bb.gin.ntt.net (129.250.5.13) 54.316 ms 54.275 ms 52.426 ms 10 130.94.58.116 (130.94.58.116) 52.211 ms 58.061 ms 54.065 ms
よくあるツール
- 従来の UNIX Traceroute は 宛先ポートが 33434 から始まり、プローブごとに 1 ずつ増加する UDP パケットを送信します。 一般的なデフォルト設定は、ホップごと（またはTTL増分ごと）に3つのプローブですが、これは通常設定可能です。プローブパケットが最終宛先に到達すると、ホストはICMP宛先到達不能パケットを返します（これらのUDPポートでアプリケーションがリッスンしていないことを前提としていますが、そうではありません。 トレースルートの終了を示します。
- Windows Traceroute（より具体的にはtracert.exe）は、その 従来のUNIX Traceroute実装のUDPプローブではなく、ICMPエコー要求プローブを使用している点で注目に値します。 プローブパケットが最終宛先に到達すると、トレースルートの終了を示すICMPエコー応答パケットが返されます。
- 「My Traceroute」（MTR）は、ICMPプローブパケットも実行できる人気のプログラムです。 ICMPプローブパケット。 MTRと他のプログラムとの最も顕著な違いは、Tracerouteプローブを無限ループで実行する点である。MTRは、長期間にわたって多数のプローブを送信するため、複数の並列経路を見つけるのに非常に優れています。
最新のTraceroute実装では、ユーザーはUDP、ICMP、またはTCPのプローブパケットを指定できます。
トレースルート分析に関するよくある問題
以下では、Traceroute メトリックの誤った解釈が、特に 3 つの主要な ケース: パス識別、遅延、パケット損失を分析する際に、誤診につながることが多い理由を説明します。
パス識別：非対称転送パス
Tracerouteは前方の経路のみを表示します。トレースルートによって報告されるパスが両方向であるというのは、よくある誤解です。 逆方向の経路はTracerouteでは見えず、各ホップで全く異なる可能性があり、経路上の異なるネットワークによって異なる場合も多い。Tracerouteは、目的地までの経路が妥当かどうかを判断するのに役立ちます。逆方向の経路を確認するには、宛先から発信元への別のトレースルートが必要です。
遅延分析：ICMP優先順位付け／レート制限による遅延
個々のホップにおける遅延の急増は、ルーターが「ICMP TTL Exceed」パケットの生成を優先順位を下げ、レート制限することによって引き起こされることが多い。一方、データパケットは専用回路によってはるかに高速に転送され、ラインレートでパケットを切り替えることができ、ルーターのCPUが忙しい時にCPUを使わなくても済む。特定のホップで高遅延が検出されたとしても、最終宛先へのトラフィックに影響があるとは必ずしも言えません。It is crucial to verify whether the increased latency persists in the subsequent hops 。
例（Windows）：
>tracert www.amazon.com Tracing route to cf.47cf2c8c9-frontier.amazon.com [3.164.99.110] over a maximum of 30 hops: 1 7 ms 5 ms 6 ms mynetwork.home [192.168.2.1] 2 13 ms 39 ms 19 ms 142.124.37.243 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 12 ms 10 ms 11 ms 142.124.123.156 7 14 ms 24 ms 9 ms 142.124.125.80 8 15 ms 36 ms 7 ms 64.230.97.145 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 9 ms 6 ms 12 ms server-3-164-99-110.yto53.r.cloudfront.net [3.164.99.110]
宛先までの遅延時間は、以前のホップで報告された遅延時間よりも低い。したがって、中間ホップにおける高い遅延は無視できる。
ホップ/パケット損失分析：持続しない一時的なパケット損失
トレースルートが中間ホップでパケットを停止または破棄しているように見えるのは、誤解を招く可能性があります。中間ホップでのパケット損失は、必ずしも最終宛先へのトラフィックも損失することを意味するものではありません。後続のホップにおけるパケット損失を確認することが重要です。
Tracerouteで確認された遅延やパケット損失は、後続のホップで遅延が低減したり、パケット損失が少なくなったり、あるいは全く発生しない場合は無視すべきです。なぜなら、後続のホップに到達するすべてのパケットは、前続のホップによって転送される必要があるからです。Tracerouteで遅延やパケットロスが発生し、それが最後まで続く場合は、深刻な問題を示している可能性があります。その問題は、影響を受ける最初のホップの直前の順方向パスにある場合もあれば、そのホップとその後のホップからの戻りパスにある場合もあります。
例（Windows）：
>tracert www.google.com Tracing route to www.google.com [142.250.137.147] over a maximum of 30 hops: 1 9 ms 6 ms 4 ms mynetwork.home [192.168.2.1] 2 8 ms 9 ms 5 ms 142.124.37.243 3 * * * Request timed out. <------ Hidden hops 4 * * * Request timed out. 5 * * * Request timed out. 6 14 ms 10 ms 8 ms 142.124.123.154 7 * 9 ms 27 ms 142.124.125.82 <------ Busy routers 8 13 ms 6 ms * 64.230.97.147 9 * * * Request timed out. 10 * 17 ms 17 ms 192.178.99.39 11 9 ms 15 ms 11 ms 192.178.99.24 12 14 ms 24 ms 12 ms 108.170.229.1 13 10 ms 11 ms 13 ms 142.250.208.188 14 * * * Request timed out. <------ Hidden hops 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 15 ms 9 ms 12 ms pnyyzb-in-f147.1e100.net [142.250.137.147] Trace complete.
「リクエストがタイムアウトしました」というエラーが多数発生しているにもかかわらず、トレースログではGoogleへの接続が良好であることが確認されています。
- The Destination Was Reached: 最後の行（ホップ20）は、Googleへの接続が成功したことを示しています。
- Latency is Excellent: 目的地までの往復時間は約12 ms （ミリ秒）で、これは非常に優れています。
- The “Timeouts” (*) Are Normal:
- Hops 3–5: これらはISPの内部ルーターです。それらは「見えない」ように設定されているが、後続のパケットを正常に通過させた。
- Hops 14–19: これはGoogleのセキュリティファイアウォールです。これはtraceroute追跡ツールをブロックしますが、実際のデータは最終サーバーに到達できるようにします。
トレースルートのメトリクス
Tracerouteが報告する、ネットワークの問題診断に役立つ主要な指標を以下に示します。
ルーターホップ数（経路識別）
トレースルートは、送信元と宛先間のルーターのホップ数の一覧を表示します。Tracerouteが報告する経路には、複数の要因が影響します。
- 非対称ルーティング
送信元デバイスから宛先デバイスへのtracerouteを実行すると、その結果によって表される経路は「順方向経路」と呼ばれます。同じ送信元デバイスの視点から見ると、宛先デバイスから送信元デバイスに戻る経路は「逆経路」と呼ばれます。ネットワークにおいては、順方向の経路を知っているからといって、逆方向の経路も自動的に分かるとは限らない。場合によっては経路が異なることがあり、これは「非対称ルーティング」と呼ばれます。 理想的には、これらの経路は同一であるか、少なくとも非常に類似しているべきである。両者の差が大きい場合、パフォーマンス上の問題が発生する可能性がある。そのため、順方向パスと逆方向パスの両方を確認することが非常に重要であり、そのためには送信元デバイスと宛先デバイスの両方からtracerouteを実行する必要があります。
- 負荷分散と複数パス
ネットワーク経路には、パケットを複数のルーターに分散するネットワーク層3（L3）ロードバランサーが存在する可能性があります。このような場合、プローブパケットは、ネットワークパス上では実際には同じ「ホップ」にある異なるルーターに到達する可能性があります。 ホップを評価する際には、単一のtraceroute結果の中に、複数の、場合によっては不均等な前方経路が表される可能性を考慮することが不可欠です。
Example Output:
4 p16-1-0-0.r21.asbnva01.us.bb.gin.ntt.net (129.250.5.21) 0.571 ms 0.604 ms 0.594 ms 5 p16-4-0-0.r00.chcgil06.us.bb.gin.ntt.net (129.250.5.102) 25.981 ms p16-1-2-2.r21.nycmny01.us.bb.gin.ntt.net (129.250.4.26) 7.279 ms 7.260 ms 6 p16-2-0-0.r21.sttlwa01.us.bb.gin.ntt.net (129.250.2.180) 71.027 ms p16-1-1-3.r20.sttlwa01.us.bb.gin.ntt.net (129.250.2.6) 66.730 ms 66.535 ms
この例では、トラフィックは次の2つのパス間で負荷分散されます。
- アッシュバーン（バージニア州） – シカゴ（イリノイ州） – シアトル（ワシントン州）
- アッシュバーン バージニア – 新しいヨーク ニューヨーク – シアトル ワシントン州
MPLS/トンネルとTraceroute
ネットワークが MPLSやトンネルを使用してバックボーンを介してIPトラフィックを伝送する場合、これらの技術で採用されているパケットカプセル化により、tracerouteの結果で複数のネットワークホップが隠蔽されたり、複数のホップで同じ遅延が報告されたりする可能性があります。
Example Output:
1 te2-4.ar5.PAO2.gblx.net (69.22.153.209) 1.160 ms 1.060 ms 1.029 ms 2 192.205.34.245 (192.205.34.245) 3.984 ms 3.810 ms 3.786 ms 3 tbr1.sffca.ip.att.net (12.123.12.25) 74.848 ms 74.859 ms 74.936 ms 4 cr1.sffca.ip.att.net (12.122.19.1) 74.344 ms 74.612 ms 74.072 ms 5 cr1.cgcil.ip.att.net (12.122.4.122) 74.827 ms 75.061 ms 74.640 ms 6 cr2.cgcil.ip.att.net (12.122.2.54) 75.279 ms 74.839 ms 75.238 ms 7 cr1.n54ny.ip.att.net (12.122.1.1) 74.667 ms 74.501 ms 77.266 ms 8 gbr7.n54ny.ip.att.net (12.122.4.133) 74.443 ms 74.357 ms 75.397 ms 9 ar3.n54ny.ip.att.net (12.123.0.77) 74.648 ms 74.369 ms 74.415 ms 10 12.126.0.29 (12.126.0.29) 76.104 ms 76.283 ms 76.174 ms 11 route-server.cbbtier3.att.net (12.0.1.28) 74.360 ms 74.303 ms 74.272 ms
遅延時間（RTT）
Tracerouteによって報告されるレイテンシは、パケットがホップに到達し、送信元に戻ってくるまでの「往復」時間を示します。通信中、遅延に影響を与える要因は複数存在する。
- Propagation Delay
信号が物理媒体を介して目的地に到達するまでの時間。光ネットワークの場合、100キロメートルの光ファイバーでは、往復伝搬遅延は約1ミリ秒になります。
- Serialization Delay
一般的に、パケット全体を受信するまでは、出力インターフェースへのパケット送信を開始することはできません。シリアル化遅延を計算するには、パケットのサイズをリンク速度で割るだけです。リンク速度が高いほど、シリアル化遅延は小さくなる。
- Queueing Delay
インターフェースがビジー状態の場合、送信するパケットはキューに格納される必要がある。インターフェースが飽和状態に近づくと、キューに格納されるパケットの割合が指数関数的に増加し、著しい遅延を引き起こす可能性があります。
Tracerouteによって報告されるレイテンシ値は、以下の要素から構成されています。
- プローブパケットが特定のルーターに到達するまでの時間、加えて
- そのルーターがICMP TTL超過パケットを生成するのにかかる時間に加えて、
- ICMPパケットがTracerouteの送信元に戻ってくるまでの時間
ルーターはICMPパケット（低速パス）に低い優先度を与えることが多く、CPUによって処理されるICMPパケットは、CPUが処理する他の優先度の高いタスクによって遅延する可能性がある。ルーターを通過するデータパケットは、これらの遅延が発生しない高速経路を通ります。実際に問題が発生した場合、後続のホップで遅延が増加し続けます。
パケットドロップ
Traceroute が「停止」または「パケットをドロップ」した場所のレポート。 これは必ずしも、目的地との接続に問題があることを意味するものではありません。ホップでのパケットドロップは、パス上のネットワークの問題として挙げられることが多いが、通常はそうではない。 ルーターは、さまざまな理由（レート制限、CPU競合、インターフェースの混雑など）でTracerouteプローブパケットを破棄する場合があります。
あるホップでパケットがドロップされた後、同様の頻度で後続のホップでもパケットがドロップされる場合は、問題が発生していることを示しています。しかし、最初のホップでパケットがドロップされても、その後のホップでドロップされない場合は、多くの場合、問題になりません。
Reverse DNS
Tracerouteツールは、ルーターのIPアドレスと名前の逆引きDNSルックアップを実行できます。 これらの値は標準的な形式に従っていないかもしれませんが、ネットワーク経路のさまざまな側面を理解するのに大いに役立ち、トラブルシューティングに役立ちます。
- 場所識別子 – IATA空港コード、CLLIコード、任意の値。
- ルーターの種類／役割 – コア ルーター、エッジ ルーターなど
- ネットワーク境界 – ネットワーク境界とは、管理ポリシーが変更され、容量が最も制限されるハンドオフポイントであり、多くの場合、戻り経路の変更や混雑を引き起こします。
- インターフェースの種類 – 10ギガビットイーサネット、ギガビットイーサネット、ATMなど
例えば、 xe-11-1-0.edge1.NewYork1.Level3.netを考えてみましょう。xe-#-#-#という命名規則は、Juniper 10GEインターフェース（FPC 11、PIC 1、ポート0）を表します。FPC 11が存在するということは、少なくとも12スロットのシャーシであることを示しています。
ネットワーク境界は、DNS名から簡単に検出できる場合がある。
4 te1-2-10g.ar3.DCA3.gblx.net (67.17.108.146) 5 sl-st21-ash-8-0-0.sprintlink.net (144.232.18.65)
Tracerouteの先へ： Digital Experience Management
Tracerouteはネットワーク経路に関する基本的な情報を提供するものの、ほとんどのユーザーはより詳細な情報、誤解のリスクの低減、そしてユーザーエクスペリエンスを管理するための積極的なアプローチを求めている。NetskopeのDigital Experience Management (DEM) は、詳細なパフォーマンス メトリクスをプラットフォームに統合することで、Traceroute の固有の制限に対処するように設計されています。 DEMは、交通の流れのあらゆる段階における状況に応じた可視性を提供します。これにより、ネットワークパフォーマンスに関するより正確で実用的な情報が得られます。
1. Path Identification: Asymmetric Forwarding Paths
経路識別における主な制約は、Tracerouteが順方向の経路しか表示しないことであり、逆方向の経路やエンドツーエンドの流れは表示されない。視界の悪さは、実際のルートや遅延の原因に関して、大きな曖昧さを生み出す。
この曖昧さを解消し、経路識別をより深く掘り下げるために、DEMはデバイスからアプリケーションまで完全な可視性を提供します。DEMは、デバイスからアプリケーションに至るまでのあらゆるステップにおける、実際のユーザー体験とパフォーマンスを監視します。この多層的な可視性により、ユーザーのトラフィックがたどる経路全体を正確に測定し、往復フロー全体を把握することが可能になります。詳細については、 「ユーザー概要」をご覧ください。
2. Latency Analysis: Delays from ICMP Prioritization/Rate Limiting
よくある誤診の原因は、遅延スパイクが、ルーターがICMP TTL超過応答の優先順位を下げたり、レートを制限したりすることによって引き起こされる偽陽性であることが多いからです。これは、データがネットワークの転送能力ではなく、ルーターのCPU負荷を反映していることを意味します。
真のネットワークおよびアプリケーションの遅延を明確に把握するために、 Netskope DEM リアルユーザーアクティビティモニタリング。 DEMは、制御プレーンの応答ではなく、実際のユーザーアクティビティの監視とトラフィック分析に基づいてパフォーマンスを測定します。実際のトラフィックのパフォーマンス指標を追跡することで、DEMはアプリケーションとネットワークの真のパフォーマンスを把握します。
3. Hop/Packet Loss Analysis: Spikes and Drops That Do Not Persist
Traceroute でパケット損失や高遅延を診断するのは困難です。なぜなら、一時的なスパイクやドロップが持続しない場合、誤った が発生し、実際の問題とネットワークノイズを区別するのが難しくなるからです。
障害の影響と範囲を明確にするために、DEM イベントの診断、予測、優先順位付けを行うアラートを発し、誤検知を効果的に削減します。 メトリクスは、デバイスの状態、ネットワーク、アプリケーションのパフォーマンスなど、ユーザーエクスペリエンスに関する貴重なデータを提供し、あらゆる障害の範囲と影響を即座に明確にします。このコンテキストデータは、パケット損失や遅延に関する潜在的な問題を包括的に診断するのに役立ちます。