- ノードXの後にトレースルートに星が表示されるのはなぜですか？
- サービスが機能せず、ノードXでトレースアウトが中断します-これはノードXの問題を意味しますか？
- WindowsとUnixで同じトレースが異なる結果を示すのはなぜですか？
- トレースルートが特定のノードで大きな遅延を示すのはなぜですか？
- インターネット経由でトレースすると、トレースルートに「グレー」アドレスが表示されるのはなぜですか？
- ルーターが必要なアドレスでトレースアウトに応答しないのはなぜですか？
- trussroutに「間違った」ドメイン名が表示されるのはなぜですか？
- トレースルートの結論が、直感的に予想されるものと異なることが多いのはなぜですか？
トレースルートに関連するネットワークエンジニアと管理者は、2つのカテゴリに分類されます。定期的に自分自身と周囲の人に質問し、回答するのをためらいます。
このトピックで
は 、上記の質問に対する回答
は提供
していません 。 またはほとんどありません。 しかし、彼は、彼らに質問するべきかどうか、もしそうならいつ、誰に質問すべきかについて考えることを提案します。
輸送ルートとの関係について、Richard Nasseve SteenbergenはNANOG-47（2009）会議でレポートを作成しました。これらの論文はすべての関係者に研究することをお勧めします。
Tracerouteによる（正確に）トラブルシューティングの実践ガイド（PDF、222 KB） （もちろん、英語）。
ここで詳細を読み直すことはしません（読みたい人）。「私は...を示す痕跡があります」と叫んで助けを求める前に、心に留めておくべき一連の議論と結論だけを取り上げます。
( ) — . , , , , . , . , , .
いくつかの事実（詳細に入ることなく）
- ネットワークを通過するパケットの遅延は、シリアル化、バッファリング、配布などのいくつかの要素で構成されています。 それぞれの要因は、あなたが考えているよりも複雑です。
- トレースアウトが示す遅延はさらに複雑です。ルーターは、中継パケットとはまったく異なる方法で自分宛てのパケットを処理します。 この状況は、トレースアウトが示す遅延値の特定の性質につながります。 このことから導かれることはできませんが、読むことができなければなりません。
- インターネットトラフィックは、ほとんどの場合、クライアントからサーバーへ、およびサーバーからクライアントへと異なる方向に行きます。 トレイアウトは、常に両方向の合計遅延と、一方向のみのトレースを示します。
- トレースルートへの複数のインターフェイス（ルーター）を持つデバイスのソースアドレスの表示は、要求の送信元のインターフェイスの選択に影響しません。 そして、それは-回答が送信されるリターンパスの選択に影響します。 これらのトレースは出力には表示されませんが、この方法では、並列リターンルートの遅延差を測定できます。
- インターネットバックボーンのどこかでL3バランシングを使用すると、同じトレース内の異なるパケットが異なる方法で送信される可能性があります。 このような振る舞いは、誰もが正しく読むことができない結論を解釈することを困難にします。
- トレースルートに応答する場合、最新のルーターは、ICMP応答のソースIPアドレスを発信インターフェイスのアドレスに設定することを要求するRFC1812の4.3.2.4節の要件に準拠していません。 代わりに、トレースアウト要求が受信されたインターフェイスのアドレスと同じに設定します（TTL = 1のパケット）。 ただし、逆の場合、トレーシールートの結論を読むのははるかに困難です。
- バックボーンネットワーク内のMPLSスイッチングの存在は（今日、これは自尊心のある大規模プロバイダーの場合です）、トレースアウトへの応答を送信する直観に反する方法になり、遅延を計算するあまり明白でない方法につながります。
最も重要な調査結果のいくつか（私の創造的な理解）
- traisoutは、見た目ほど単純なものではありません。 使用できる必要があります。 そのためには、その仕組みを理解する必要があります。
- ほとんどの管理者とサービスエンジニアは、通常のユーザーはもちろんのこと、理解も方法もわかりません。 この状況は、非常に多くの場合、誤報、誤った診断などにつながります。
- trisrutuの争いへのTracyroute。 Windowsの標準tracertユーティリティとLinuxのtracerouteは異なる方法で実装され、異なる結果を生成する可能性があります。 WindowsはICMPを送信し、LinuxはUDPを送信します。トレースパス上のファイアウォールは、プロトコルごとに異なるフィルタリング設定を持つ場合があります。
- トレース結果の解釈には、経験と迅速な機知が必要です。 間接データに基づいて推測することによってのみ重要な結論を下すことができますが、他のものはまったく明確ではなく、「最も可能性が高い」まで正確です。
合計
あなたが顧客なら
「なぜこのようにトレースを解釈するのですか？」という質問に対する答えが完全に確実でない限り、プロバイダー、インテグレーター、ベンダー、企業のヘルプデスクなどの技術サポートを邪魔しないでください。最良の場合は、単に無視されるか送信されます。 最悪の場合、経験のないサポートスタッフに誤ったバージョンの正確さを納得させることができます。その結果、彼らは間違った場所で問題を掘りに行くことになります。
サービスに問題は見られない（すべてが機能している）が、トレースルートの出力に気に入らない場合は、アラームを発する前に慎重に検討してください。 単に結論を誤って解釈している可能性が非常に高いです。 非常にまれに、1つのトレースルートを使用して問題を判断できます。 また、実際に問題がある場合は、通常、トレースアウトなしでデモンストレーションする方が簡単です。
あなたがパフォーマーの場合
トレースアウトの撤回に関する他人の解釈にだまされないでください。 自分の頭で考えてください（常に歓迎-キャップ）。 一般に、問題に関するメッセージがトレースの撤回で始まる場合、これは、何かを行う前に、以下に記載されている情報を個人的に再確認する必要があることを示しています。
リチャードのプレゼンテーションを読んでください。 トラブルシューティングの主なツールとしてtraceoutを使用する場合は注意してください。解釈を間違えるのは非常に簡単であり、明確な結論を出すには情報が十分でないことがよくあります。 トレースアウトの測定値を他の利用可能なデータと常に比較し、可能であれば追加情報またはドラフト情報としてのみ使用してください。