ping テストでパケット損失やネットワーク障害が示された場合、リンクテストツールを使用して原因を特定できます。このトピックでは、My Traceroute (MTR) ツールを使用したリンクテストの方法と、その結果の分析方法について説明します。
テストプロセス
次の図は、リンクテストのプロセスを示しています。
IP Address Query - IPLark などの Web サイトにアクセスして、オンプレミスネットワークのパブリック IP アドレスを取得できます。
宛先サーバーは、宛先サービスのドメイン名またはパブリック IP アドレスです。
ツールの概要
My Traceroute (MTR) は、ping と traceroute の機能を組み合わせたネットワーク診断ツールです。単一のリンクトレースを実行する 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 の公式 Web サイトにアクセスして WinMTR をダウンロードします。
WinMTR パッケージを解凍し、WinMTR をダブルクリックして実行します。
使用方法
[Host] フィールドに、宛先サーバーのドメイン名または IP アドレスを入力します。
重要宛先サーバーのドメイン名または IP アドレスにスペースを含めることはできません。
他の機能を使用したり、他のパラメーターを設定したりすることもできます。機能とパラメーターについては、次の表で説明します。
機能またはパラメーター
説明
[テキストをクリップボードにコピー]
テスト結果をテキスト形式でクリップボードにコピーします。
[HTML をクリップボードにコピー]
テスト結果を HTML 形式でクリップボードにコピーします。
[テキストをエクスポート]
テスト結果を指定したファイルにテキスト形式でエクスポートします。
[HTML をエクスポート]
テスト結果を指定したファイルに HTML 形式でエクスポートします。
[オプション]
オプションパラメーター。次の設定が含まれます。
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 など)。このエリアの例外は 2 種類に分類できます。
クライアントのオンプレミスネットワークに関連するノードで例外が発生した場合は、オンプレミスネットワークのトラブルシューティングと分析を行います。
ローカルネットワークプロバイダーのネットワークに関連するノードで例外が発生した場合は、問題をローカルキャリアに報告します。
キャリアネットワーク
キャリアネットワーク (サンプル図のエリア B など) は、複数のバックボーンネットワークを通過する場合があります。このエリアで例外が発生した場合は、異常なノードの IP アドレスが属するキャリアを照会できます。その後、直接または Alibaba Cloud テクニカルサポートを通じて、対応するキャリアに問題を報告できます。
宛先サーバーのオンプレミスネットワーク
これは、宛先ホストのネットワークプロバイダーのネットワークです (サンプル図のエリア C など)。このエリアで例外が発生した場合は、宛先ホストのネットワークプロバイダーに問題を報告できます。
中間リンクの一部でリンクの負荷分散が有効になっている場合、mtr コマンドは最初と最後のノードのみを番号付けして統計を収集します。中間ノードについては、対応する IP アドレスまたはドメイン名のみが表示されます。
メトリック分析ガイド
ネットワークリンクの接続性やパフォーマンスを分析するには、Loss% (パケット損失率)、Avg (平均遅延)、StDev (標準偏差)、およびその他の遅延メトリックに基づいて包括的な分析を実行できます。次のセクションでは、これらのメトリックに基づいてリンクの接続性を分析するための基本的なアプローチについて説明します。
Loss% (パケット損失率)
いずれかのノードの Loss% (パケット損失率) がゼロでない場合、そのネットワークホップに潜在的な問題が存在する可能性があります。ノードでのパケット損失は、通常、次の 2 つの理由のいずれかによって引き起こされます。
キャリアがセキュリティまたはパフォーマンス上の理由からノードの ICMP 送信レートを制限している。これによりパケット損失が発生します。
ノードに障害がある。これによりパケット損失が発生します。この場合、異常なノードとその後のノードでのパケット損失を調べることで、パケット損失の原因を特定できます。
後続のノードでパケット損失が発生しない場合、異常なノードでのパケット損失は通常、キャリアのポリシー制限によって引き起こされます。このパケット損失は無視できます。これはサンプル図のホップ 2 に示されています。
後続のノードでもパケット損失が発生する場合、異常なノードにネットワークの問題があり、それがパケット損失を引き起こしている可能性があります。これはサンプル図のホップ 6 に示されています。
一部の後続ノードでパケット損失が発生し、他のノードでは発生しない場合、対応するノードにはポリシーベースのレート制限とネットワーク例外の両方が存在する可能性があります。この場合、異常なノードとその後のノードで継続的にパケット損失が発生し、各ノードのパケット損失率が異なる場合、通常、最後の数ホップのパケット損失率が参照として使用されます。サンプル図に示すように、パケット損失はホップ 6、7、8、9 で発生します。したがって、最終的なパケット損失は、ホップ 9 の 30.3% のレートを基準に参照されます。
Avg (平均) と StDev (標準偏差)
リンクのジッターやその他の要因により、ノードの Best と Wrst の値は大幅に異なる場合があります。Avg (平均) 値は、リンクテスト開始以降のすべてのプローブの平均であり、対応するノードのネットワーク品質をよりよく反映します。StDev (標準偏差) の値が高いほど、そのノードでのパケットの遅延値がより多様であることを示します。したがって、標準偏差値は、Avg 値がノードのネットワーク品質を正確に反映しているかどうかを判断するのに役立ちます。たとえば、標準偏差が大きい場合、パケットの遅延は一貫していません。一部のパケットの遅延は 25 ms のように低く、他のパケットの遅延は 350 ms のように高くなる可能性があります。ただし、結果として得られる平均遅延は正常に見える場合があります。この場合、Avg 値は実際のネットワーク品質を正確に反映していません。
まとめると、推奨される分析基準は次のとおりです。
StDev 値が高い場合は、対応するノードの
BestとWrstの値を確認して、例外が存在するかどうかを判断します。StDev 値が高くない場合は、Avg 値を使用して、対応するノードに例外が存在するかどうかを判断します。
説明高い または 高くない StDev 値を定義するための特定の時間範囲は存在しません。同じノードの他の列の遅延値に基づいて値を評価する必要があります。たとえば、Avg が 30 ms の場合、25 ms の StDev は高い偏差と見なされます。ただし、Avg が 325 ms の場合、同じ 25 ms の StDev は低い偏差と見なされます。
レイテンシ
遅延の急増
特定のホップの後で遅延が急激に増加した場合、そのノードにネットワーク例外が存在する可能性があります。サンプル図に示すように、ホップ 6 の後で後続ノードの遅延が急激に増加します。これは、ホップ 6 でネットワーク例外が発生していることを示唆しています。ただし、遅延が高いからといって、必ずしも対応するノードに例外が存在するとは限りません。サンプル図に示すように、ホップ 6 の後で後続ノードの遅延が急激に増加しますが、テストデータは依然として宛先ホストに到達します。したがって、高い遅延は、リターンデータパスの問題によって引き起こされている可能性があります。これは、リバースリンクテストと組み合わせて分析できます。
ICMP レート制限による遅延の増加
ICMP ポリシーのレート制限もノードでの遅延の急激な増加を引き起こす可能性がありますが、後続ノードの遅延は通常、正常に戻ります。サンプル図に示すように、ホップ 9 では 30% のパケット損失率と遅延の大幅な増加が見られます。ただし、後続ノードの遅延はすぐに正常に戻ります。したがって、このノードでの遅延の急増とパケット損失は、ポリシーベースのレート制限によって引き起こされていると結論付けることができます。
サンプル分析と結論
サンプル図と分析ガイドに基づいて、次の結論を導き出すことができます。
クライアントのオンプレミスネットワークエリアでは、ホップ 2、6、7、8、9 でパケット損失が発生します。ただし、後続のホップ 3、4、5、10、11、15 では重大なパケット損失は発生しません。対応するビジネスネットワークリクエストが正常である場合、ホップ 2、6、7、8、9 でのパケット損失は ICMP レート制限によって引き起こされている可能性が高いと判断できます。
ホップ 4 の
Wrst値は高いですが、Avg値は高くありません。これは、プローブの 1 つの間にネットワークまたはデバイスのパフォーマンスの変動によって引き起こされた一時的なネットワークリンクの変動が原因である可能性があります。リンク全体のノードの平均遅延は 1.8 ms から 17.6 ms の間であり、これはリンク全体のネットワーク遅延が低いことを示しています。
これらの結論に基づいて、例のネットワークリンクは正常であると判断できます。実際のビジネスネットワークで変動が発生する場合は、リバースリンクテストと組み合わせて結果を分析できます。
ネットワーク結果を分析するアプローチは柔軟です。このトピックで説明する方法は、メトリックを分析するための一般的な方法です。実際の分析では、特定の状況に基づいて包括的な評価を行い、正確な結論を導き出す必要があります。一方向のリンクテストで明確な結論が得られない場合は、リバースリンクテストと組み合わせて、より詳細な分析と問題の診断を実行できます。
一般的なリンク例外シナリオ
一般的なリンク例外シナリオは、Linux オペレーティングシステムの mtr コマンドを例として説明しています。実際の結果は、オペレーティングシステムやツールによって異なる場合があります。
宛先ホストでの不適切なネットワーク構成
次の図に示すように、宛先アドレスで 100% のパケット損失が発生します。これは、最初はパケットが到着していないように見えるかもしれません。ただし、ファイアウォールや iptables などの宛先サーバーのセキュリティポリシーが ICMP を無効にしている可能性が非常に高いです。これにより、宛先ホストは確認応答を送信できなくなります。このシナリオでは、宛先サーバーのセキュリティポリシー構成を確認できます。
ICMP レート制限
次の図に示すように、宛先アドレスでのパケット損失率が高くなっています。これは、最初はパケットが到着していないように見えるかもしれません。ただし、ファイアウォールや iptables などの宛先サーバーのセキュリティポリシーやキャリアポリシーが ICMP を無効にしている可能性が非常に高いです。これにより、宛先ホストは確認応答を送信できなくなります。このシナリオでは、宛先サーバーのセキュリティポリシー構成を確認するか、リバース MTR リンクテストと組み合わせて包括的な分析を実行できます。
リンク内のループ
次の図に示すように、パケットはホップ 5 の後にループに入り、宛先サーバーに到達できません。これは通常、キャリアのノードでの異常なルーティング構成が原因で、リンクにループが作成されます。このシナリオでは、ノードが属するキャリアに連絡して問題を解決できます。
リンクの中断
次の図に示すように、ホップ 4 の後にフィードバックが受信されません。Loss%、Last、Avg、Best などのメトリックの統計は表示されません。これは通常、対応するノードでの中断が原因です。リバースリンクテストを実行してさらに確認できます。このシナリオでは、ノードが属するキャリアに連絡して問題を解決できます。
