はじめに
MTR（元々はMattのTraceRoute、現在はMy TraceRoute）は、UNIX / Linux管理者の武器庫にある便利で軽量なツールであり、遅延、パケット損失、ルーティングエラーなどの一般的なネットワークの問題を特定して診断するのに役立ちます。これは、tracerouteとpingの結果を1つのコマンドで組み合わせて表示する強力な2-in-1ツールです。 MTRの使用の基本と、MTRが提供するデータを解釈する方法を見ていきましょう。
前提条件
- Linuxサーバーが必要です。サーバーがまだない場合は、VPSホスティングページにアクセスして、30秒以内に新しいサーバーを起動できます
MTRのインストール
MTRパッケージは、今日人気のあるLinux（またはUNIXベース）オペレーティングシステムのほとんどで利用できます。
Ubuntu / DebianにMTRをインストールします：
sudo apt-get install mtr-tiny
mtr-tinypackageは、mtrのコマンドラインのみのバージョンです。 パッケージ。mtrパッケージには、X-11グラフィカルインターフェイスのサポートが含まれています。
CentOS / FedoraにMTRをインストールします：
yum install mtr
Arch LinuxにMTRをインストールする：
pacman -S mtr
FreeBSDにMTRをインストールする：
pkg install mtr
。
MTRの仕組み
MTRが生成する出力を理解するには、MTRがどのように機能するかを知っておくと役立つ場合があります。 tracerouteの方法に既に精通している場合 コマンドが機能する場合、この説明はおなじみのように聞こえます。
MTRは、mtrのターゲットIP/ホスト名宛てのICMPエコー要求パケットを生成します 指図。最初のパケットの存続時間（TTL）値は1になります。そのパケットが、最終的な宛先へのパス上のゲートウェイであるルーターに到着すると、受信側ルーターはTTLを1減らし、0にします。 TTLが0に達すると、ルーターはパケットをドロップし、元の送信者にICMPTimeExceededパケットを送信します。このリターンパケットには送信者のIPアドレスが含まれており、MTRはこのIP（または解決できる場合はホスト名）を最初のホップとして表示します。次に、TTLが2の別のICMPエコー要求パケットを送信し、TTLの有効期限からICMP Time Exceededパケットを受信すると、このデバイスを2番目のホップとしてリストし、宛先がICMPエコー応答パケットを返すまで続きます。 。
。
MTRレポートを読む
MTRは、発信元と宛先の間の各ネットワークホップを一覧表示するだけでなく、発信元ホストから各ホップまでの途中のパケットのラウンドトリップ時間に関連する統計も追跡します。このラウンドトリップ時間は、多くの場合、レイテンシと呼ばれます。 。
MTRが教えてくれることをよりよく理解するために、GoogleのパブリックDNSへのルートをたどる例を見てみましょう。
sudo mtr -r 8.8.8.8
[sample results below]
HOST: endor Loss% Snt Last Avg Best Wrst StDev
1. 69.28.84.2 0.0% 10 0.4 0.4 0.3 0.6 0.1
2. 38.104.37.141 0.0% 10 1.2 1.4 1.0 3.2 0.7
3. te0-3-1-1.rcr21.dfw02.atlas. 0.0% 10 0.8 0.9 0.8 1.0 0.1
4. be2285.ccr21.dfw01.atlas.cog 0.0% 10 1.1 1.1 0.9 1.4 0.1
5. be2432.ccr21.mci01.atlas.cog 0.0% 10 10.8 11.1 10.8 11.5 0.2
6. be2156.ccr41.ord01.atlas.cog 0.0% 10 22.9 23.1 22.9 23.3 0.1
7. be2765.ccr41.ord03.atlas.cog 0.0% 10 22.8 22.9 22.8 23.1 0.1
8. 38.88.204.78 0.0% 10 22.9 23.0 22.8 23.9 0.4
9. 209.85.143.186 0.0% 10 22.7 23.7 22.7 31.7 2.8
10. 72.14.238.89 0.0% 10 23.0 23.9 22.9 32.0 2.9
11. 216.239.47.103 0.0% 10 50.4 61.9 50.4 92.0 11.9
12. 216.239.46.191 0.0% 10 32.7 32.7 32.7 32.8 0.1
13. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. google-public-dns-a.google.c 0.0% 10 32.7 32.7 32.7 32.8 0.0
MTRレポートには、デフォルトで次の列が表示されます。
– Loss％ =ICMP応答が受信されなかったパケットの割合。
– Snt =各ホップに送信されたパケットの数。
–最後 =最後のtracerouteプローブのラウンドトリップ時間（ミリ秒単位）。
–平均 =すべてのtracerouteプローブの平均ラウンドトリップ時間（ミリ秒単位）。
–ベスト =すべてのtracerouteプローブの最短ラウンドトリップ時間（ミリ秒単位）。
– Wrst =すべてのtracerouteプローブの最長ラウンドトリップ時間（ミリ秒単位）。
– StDev =各ホップの標準偏差プローブの結果。
。
MTRからのライブレポートの取得
ターゲットIP（またはホスト名）のみを使用してMTRを実行すると、セッションを終了するか、breakコマンド（Ctrl+C）を実行するまで継続するライブレポートが得られます。 。
sudo mtr 8.8.8.8
一部のオペレーティングシステムには
sudoが必要ですmtrを実行する前に 指図;他の人はしません。
。
MTRを一時停止する場合は、pを押します。 。 MTRは、一時停止中に収集されたすべてのカウントを保持し、スクリーンショットを撮ったり、データをクリップボードにコピーしたりできるようにします。スペースバーでMTRの一時停止を解除します。
。
固定カウントMTRレポートの生成
-rを使用して、特定の数のトレースプローブの後にMTRレポートを生成することもできます。 オプション（長い形式は--report ）。デフォルトのカウント数は10ですが、別のカウント数でMTRを実行する場合は、-cを使用してください。 （--report-cycles ）オプションも。たとえば、200カウントを超えるレポートを生成する場合：
sudo mtr -rc 200 8.8.8.8 [long form] sudo mtr --report --report-cycles 200 8.8.8.8
-rで実行されるすべてのMTR オプションは、カウントの全数が完了するまで、（上記のライブレポートとは異なり）出力を生成しません。 MTRは、デフォルトで1秒に1回一連のトレースプローブを送信するため、レポートはカウント数に等しい秒数（上記の例では200秒）で完了する必要があります。
。
その他の便利なオプション
MTRの使用中に役立つと思われるオプションは他にもいくつかあります。引数を必要としないもの（-rなど） ）を同じオプション文字列でチェーン化できます（例：-rn ）。引数を必要とするオプションは、それが最後のオプションであり、その後に引数が続く場合にのみ、これらのチェーンの1つに含めることができます（例：-rnc 200 。
-
-n：(長い形式の--no-dns）DNSホスト名ルックアップを無効にします。nキーをライブレポート中に使用して、DNSルックアップの無効化と有効化を切り替えることもできます。 -
-u：ICMPエコー要求パケットの代わりにUDPデータグラムを送信します。uキーは、ライブレポート中にUDPとICMPを切り替えることもできます。 -
-w：(長い形式の--report-wide）-rの代わりに使用します ただし、長いホスト名を切り捨てないレポートを生成します。 -
-i*:(長い形式の--interval）テストプローブ間の間隔を秒単位で指定します。デフォルトの間隔は1秒です。 -
-4：テストをIPv4に制限します。 -
-6：テストをIPv6に制限します。
。
レイテンシーのMTRデータの分析
MTRデータの出力は、あなたまたはインターネットキャリアの1つがルーティングに関して抱えている可能性のある問題を特定するのに役立ちます。また、エンドポイント間の予想遅延のベースラインを設定するのにも役立ちます。
ここで、MTRによって生成される時間は、ICMPパケットがTTLの有効期限が切れるホップに到達するためのラウンドトリップ時間であり、その有効期限を処理するデバイスがICMP Time Exceededパケットを生成し、そのパケットがに戻るまでの時間です。発信元のデバイス。多くのルーターでは、ドロップされたパケットに対してICMP応答を実行することは優先度が低く、一部のデバイスでは完全に無効になっています。
これらの理由の1つとして、1つの中間ホップが「最後」または「最悪」の時間列に時折スパイクを示す場合があります。レイテンシーのジャンプが後続の各ホップにも伝播しない限り、実際のスループットレイテンシーではなく、その1つのデバイスの応答メカニズムからの遅延が表示されます。たとえば、次のMTR出力を考えてみましょう。
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. vl223-ar-01.nyc-ny.atlantic.net 0.0% 66 0.5 6.1 0.5 140.2 25.5 2. te0-0-1-1.rcr11.ewr04.atlas.cogentco.com 0.0% 66 1.0 1.0 0.8 2.8 0.2 3. te0-3-0-4.rcr21.ewr02.atlas.cogentco.com 0.0% 66 1.1 1.1 0.9 2.5 0.2 4. be2601.rcr24.jfk01.atlas.cogentco.com 0.0% 66 1.6 1.7 1.5 2.0 0.0 5. be2632.ccr42.jfk02.atlas.cogentco.com 0.0% 66 1.7 1.8 1.6 3.0 0.1 6. be2807.ccr42.dca01.atlas.cogentco.com 0.0% 66 8.3 8.1 7.7 12.1 0.6 7. be2113.ccr42.atl01.atlas.cogentco.com 9.1% 66 27.5 21.7 18.6 34.7 3.9 8. be2123.ccr22.mia01.atlas.cogentco.com 0.0% 66 33.0 33.4 33.0 41.5 1.1 9. be2055.ccr21.mia03.atlas.cogentco.com 0.0% 66 33.3 33.6 33.1 36.3 0.4 10. 38.104.95.170 0.0% 65 40.8 40.9 40.7 42.0 0.1 11. 209.208.7.42 0.0% 65 41.6 43.3 40.9 187.9 18.2 12. [target host] 0.0% 65 41.1 41.1 40.9 41.3 0.0
最初のホップと11番目のホップがそれぞれ平均よりもはるかに長い最悪の時間をどのように持っているかを見てください。多くの人がこのような指標を見て、スループットの待ち時間の証拠を表していると思い込んでいます。しかし、2番目と12番目のホップも同様に最悪の時間を示さないことに注意してください。後続の各ホップの最悪の時間列が同じかそれ以上の時間を示した場合、潜在的な遅延の問題を指し示すインシデントの結果を取得できます。対照的に、特にホップ6と7の間の平均時間列に注意してください。平均は8.3ミリ秒から21.7ミリ秒にジャンプし、後続の各ホップの数値は高くなります。この列は、真の遅延の例を示しています。この場合、ワシントンD.C.とジョージア州アトランタのルーター間です（この結果は、2015年の基準ではかなり正常です）。
また、中間ホップが散発的に、または一貫してパケットを完全にドロップすることもあります。繰り返しになりますが、これらのドロップが1つのデバイスに分離され、後続のすべてのホップで一貫性がない限り、ICMP Time Exceeded応答メッセージの優先順位がより重要なトランジットトラフィックに優先されるという症状である可能性が非常に高くなります（このドロップの例を見ることができます）。上記のホップ7で）。場合によっては、ネットワーク管理者は、ICMPTimeExceeded応答で応答しないようにルーターを構成します。これらのホップはトラフィックの100％をドロップしているように見えますが、それを超えるホップはまだ応答しています（この記事の最初の例では、ホップ13でこの動作の例を見て、100％の損失を示し、ホストIPを示していません。またはホスト名）。
。
次は？
この記事は、MTRツールを使用して、インターネット上のさまざまなエンドポイントへのネットワーク接続を調べる方法の概要にすぎません。学ぶべきことはまだたくさんありますが、ここに示されている情報は、発生している可能性のあるネットワークの問題を診断できるようにするための良いスタートを切るはずです。読んでいただきありがとうございます。さらに更新されたVPSホスティングのチュートリアルや、ネットワークの基本–スイッチ、ルーター、ファイアウォールなどの記事については、もう一度確認してください。
VPSホスティングサービスと仮想プライベートサーバーの詳細をご覧ください。
。
。