MTR を使用して各ホップをトレースし、リンク品質メトリックを分析することで、パケット損失とレイテンシーの問題を診断します。
テストプロセス
下図に、一般的なリンクテストのプロセスを示します。
-
「IP Address Query - IPLark」 などの Web サイトにアクセスして、オンプレミスネットワークのパブリック IP アドレスを取得します。
-
宛先サーバーとは、対象サービスのドメイン名またはパブリック IP アドレスを指します。
ツールの概要
MTR は、ping と traceroute を組み合わせたものです。 リンクを 1 回だけトレースする traceroute とは異なり、mtr は各ホップを継続的にプローブして統計を収集するため、一時的な変動の影響を低減し、より正確な mtr 結果を生成します。
Linux では、mtr パッケージをインストールして mtr を使用します。 Windows では、WinMTR を使用します。
mtr (Linux)
インストール
CentOS 6/7/8
Ubuntu/Debian
使用方法
コマンド形式
mtr は次の形式を使用します。 hostname はサービスのドメイン名、 ip はパブリック IP アドレスです。
mtr [options] hostname/ip
パラメーター
次の表に、一般的なパラメーターを示します。 完全なリストについては、 man mtr を実行してください。
|
オプションパラメーター |
説明 |
|
|
レポートモードで出力を表示します。 |
|
|
各リンクトレースの結果を個別に一覧表示します。 |
|
|
ping パケットのサイズを指定します。 |
|
|
IP アドレスの DNS 解決を無効にします。 |
|
|
送信パケットの送信元 IP アドレスを設定します。 説明
ホストに複数の IP アドレスがある場合に使用します。 |
|
-4 |
IPv4 のみを使用します。 |
|
-6 |
IPv6 のみを使用します。 |
デフォルトでは、mtr は対話モードに入ります。 [?] または [h] を押すと、 mtr の制御と表示ビューの切り替えに関するヘルプメニューが表示されます。
使用例
IPv4 を使用してネットワークを診断します。
sudo mtr -4 www.aliyun.com
出力例
mtr <宛先 IP アドレス> を実行すると、次の出力が返されます。

次の表に、デフォルトの出力フィールドの説明を示します。
|
パラメーター |
説明 |
|
Host |
ノードの IP アドレスまたはドメイン名。 |
|
Loss% |
ノードのパケット損失率。 |
|
Snt |
送信されたパケット数。 デフォルト:10。 |
|
Last |
最後のプローブのレイテンシー。 |
|
Avg |
すべてのプローブの平均レイテンシー。 |
|
Best |
すべてのプローブの最小レイテンシー。 |
|
Wrst |
すべてのプローブの最大レイテンシー。 |
|
StDev |
標準偏差。 値が高いほど、レイテンシーが不安定であることを示します。 |
WinMTR (Windows)
インストール
WinMTR はインストール不要です。 パッケージをダウンロードして解凍し、実行ファイルを実行します。
-
WinMTR の公式サイト にアクセスして WinMTR をダウンロードします。
-
パッケージを解凍し、 WinMTR をダブルクリックして実行します。

使用方法
-
[Host] フィールドに、宛先サーバーのドメイン名または IP アドレスを入力します。
重要宛先サーバーのドメイン名または IP アドレスにスペースを含めることはできません。

次の表に、追加の機能とパラメーターを示します。
機能またはパラメーター
説明
[Copy Text to clipboard]
テスト結果をテキスト形式でクリップボードにコピーします。
[Copy HTML to clipboard]
テスト結果を HTML 形式でクリップボードにコピーします。
[Export TEXT]
テスト結果をテキスト形式でファイルにエクスポートします。
[Export HTML]
テスト結果を HTML 形式でファイルにエクスポートします。
[Options]
オプションパラメーター:
-
[Interval (sec)]:プローブ間隔。 デフォルト:1 秒。
-
[Ping size (bytes)]:ping パケットサイズ。 デフォルト:64 バイト。
-
[Max. hosts in LRU list]:LRU リストの最大ホスト数。 デフォルト:128。
-
[Resolve names]:逆引きによって IP アドレスをドメイン名に解決します。
-
-
[Start] をクリックします。
[Start] が [Stop] に変わり、 WinMTR が結果を表示します。
-
十分なデータが収集されたら、 [Stop] をクリックします。
出力例
宛先サーバーのドメイン名をテストすると、次の出力が返されます。

次の表に、デフォルトの出力フィールドの説明を示します。
|
パラメーター |
説明 |
|
Hostname |
ノードの IP アドレスまたはドメイン名。 |
|
Nr |
ノードの通し番号。 |
|
Loss% |
ノードのパケット損失率。 |
|
Sent |
送信されたパケット数。 |
|
Recv |
受信したパケット数。 |
|
Best |
ノードの最小レイテンシー。 |
|
Avg |
ノードの平均レイテンシー。 |
|
Worst |
ノードの最大レイテンシー。 |
|
Last |
最後のプローブのレイテンシー。 |
|
StDev |
標準偏差。 値が高いほど、レイテンシーが不安定であることを示します。 |
結果の分析ガイド
mtr はより精度が高いため、以下の分析では mtr の結果を例として使用します。 サンプル結果を以下に示します。

ネットワークエリア
クライアントから宛先サーバーへのリンクは、通常、以下のネットワークエリアを通過します。
-
クライアントのオンプレミスネットワーク
図のエリア A のように、LAN とローカル ISP ネットワークを含みます。 例外は 2 種類に分類されます。
-
例外がクライアントのオンプレミスネットワーク内のノードで発生した場合は、オンプレミスネットワークのトラブルシューティングを行います。
-
例外が ISP ノードで発生した場合は、ローカルのインターネットサービスプロバイダー (ISP) に問題を報告します。
-
-
キャリアネットワーク
図のエリア B のような ISP バックボーンネットワークです。 ここで例外が発生した場合は、異常なノードの IP アドレスを調べてその ISP を特定します。 ISP に直接、または Alibaba Cloud テクニカルサポートを通じて問題を報告します。
-
宛先サーバーのオンプレミスネットワーク
図のエリア C のような宛先ホストプロバイダーのネットワークです。 ここで例外が発生した場合は、宛先ホストのネットワークプロバイダーに問題を報告します。
中間リンクの一部でリンクの負荷分散が有効になっている場合、 mtr は最初と最後のノードにのみ番号を付けてプローブします。 中間ノードには IP アドレスまたはドメイン名のみが表示されます。
メトリック分析
Loss%、Avg、StDev、およびレイテンシーを総合的に調べることで、リンクの接続性とパフォーマンスを分析します。
Loss% (パケット損失率)
いずれかのノードで Loss% がゼロ以外の場合、そのホップで問題が発生している可能性があります。 パケット損失は通常、次のいずれかが原因です。
-
ISP がセキュリティまたはパフォーマンス上の理由から、ノードで ICMP をレート制限しています。
-
ノードに障害が発生しています。 異常なノードとその後のノードのパケット損失状況を確認します。
-
後続のノードでパケット損失が見られない場合、その損失は通常、ISP のレート制限が原因です。 図の 2 番目のホップに示されているように、これは無視できます。
-
後続のノードでもパケット損失が見られる場合、そのノードではネットワークに例外が発生しています。 図の 6 番目のホップに示されているとおりです。
-
後続のノードにパケット損失があるノードとないノードの両方が含まれる場合、レート制限とネットワーク例外の両方が存在する可能性があります。 複数の連続したホップでパケット損失がさまざまなレートで継続的に発生する場合、最後のいくつかのホップでのレートを基準として使用します。 図では、ホップ 6〜9 でパケット損失が見られるため、最終的なパケット損失率はホップ 9 で 30.3% です。
-
Avg (平均値) と StDev (標準偏差)
リンクのジッターやその他の要因により、 Best と Wrst の値が大きく変動することがあります。 Avg はテスト開始以降のすべてのプローブを平均するため、ネットワーク全体の品質をより正確に反映します。 StDev はレイテンシー値がどの程度分散しているかを示します。 StDev が高い場合、Avg が実際の状況を正確に表していない可能性があります。 たとえば、一部のパケットのレイテンシーが 25 ms で、他のパケットが 350 ms の場合、実際のパフォーマンスが悪いにもかかわらず、平均値は正常に見えることがあります。
推奨される分析アプローチ:
-
StDev が高い場合は、
BestとWrstを確認して例外の有無を判断します。 -
StDev が低い場合は、Avg を使用してノードを評価します。
説明StDev が 高い か 低い かは、コンテキストによって異なります。 たとえば、Avg が 30 ms の場合、 StDev 25 ms は大きな変動ですが、Avg が 325 ms の場合、 小さな変動です。
レイテンシー
-
レイテンシーの急上昇
特定のホップの後にレイテンシーが急上昇した場合、そこでネットワーク例外が発生している可能性があります。 図では、6 番目のホップの後にレイテンシーが急激に増加しています。 ただし、データはまだ宛先に到達しているため、高いレイテンシーは戻りパスで発生している可能性があります。 これを逆方向リンクテストと合わせて分析します。
-
ICMP レート制限によるレイテンシーの増加
ICMP レート制限もノードでレイテンシーの急上昇を引き起こす可能性がありますが、後続のノードは通常、正常に戻ります。 図では、9 番目のホップで 30% のパケット損失と高いレイテンシーが見られますが、次のホップは正常に戻っています。 これは、急上昇がレート制限によって引き起こされていることを示しています。
分析例

サンプル結果と上記の分析ガイドに基づくと、次のようになります。
-
パケット損失はホップ 2、6、7、8、9 で発生していますが、ホップ 3、4、5、10、11、15 では発生していません。 ネットワークリクエストが正常に機能している場合、パケット損失は ICMP レート制限が原因である可能性があります。
-
4 番目のホップの
Wrstは高いですが、Avgは高くありません。 これは、1 回のプローブ中の一時的な変動が原因である可能性があります。 -
すべてのノードの平均レイテンシーは 0.4 ms から 17.6 ms の範囲であり、全体的なレイテンシーが低いことを示しています。
この例のネットワークリンクは正常です。 実際の環境で変動が発生した場合は、逆方向リンクテストの結果と合わせて分析してください。
ネットワーク分析には柔軟性が求められます。 これまでのセクションでは、一般的なメトリック分析方法について説明しました。 実際には、特定の状況に基づいて包括的な評価を行ってください。 一方向のテストで結論が出ない場合は、逆方向リンクテストと組み合わせてより深い分析を行ってください。
一般的なリンクの例外
以下の例では、Linux 上の mtr を使用しています。 実際の結果は、オペレーティングシステムやツールによって異なる場合があります。
宛先ホストの不適切なネットワーク設定
以下に示すように、宛先ノードで 100% のパケット損失が発生します。 これは、パケットが到着しなかったように見えるかもしれません。 しかし、宛先サーバーのファイアウォールや iptables などのセキュリティポリシーが ICMP 応答をブロックしている可能性があります。 宛先サーバーのセキュリティポリシー設定を確認してください。
ICMP レート制限
以下に示すように、宛先で高いパケット損失率が見られます。 ファイアウォール、iptables、または ISP のレート制限などのセキュリティポリシーが ICMP 応答をブロックしている可能性があります。 宛先サーバーのセキュリティポリシーを確認するか、包括的な分析のために逆方向 MTR テストを実行してください。

ルーティングループ
以下に示すように、パケットは 5 番目のホップの後にループに入り、宛先に到達できません。 これは通常、ISP ノードの異常なルーティング設定が原因です。 そのノードを管轄する ISP に連絡してください。
リンク中断
以下に示すように、4 番目のホップ以降、応答がなく、Loss%、Last、Avg、および Best には統計が表示されません。 これは通常、そのノードでのリンク中断が原因です。 確認のために逆方向リンクテストを使用してください。 そのノードを管轄する ISP に連絡してください。