pingコマンドを実行した後にパケット損失または接続障害が発生した場合にネットワークパスをテストするにはどうすればよいですか? - Elastic Compute Service

pingコマンドを実行してクライアントとサーバーまたはserver Load Balancer (SLB) インスタンス間のネットワーク接続をテストするときに、パケット損失が発生したり、ネットワーク接続を確立できない場合は、テストツールを使用してネットワークパスをテストし、問題を診断できます。このトピックでは、テストツールを使用してネットワークパスをテストし、テスト結果を分析する方法について説明します。

テスト手順

ネットワークパスのテストのフローチャートを次の図に示します。

链路测试流程图

説明

IP検索などのIPアドレス検索Webサイトにアクセスして、ローカルネットワークのパブリックIPアドレスを取得できます。

テストツール

MTRは、tracerouteとpingの機能を組み合わせてネットワークパスの正常性をチェックするネットワーク診断ツールです。 MTRは、ネットワークパスのすべてのノードを継続的にプローブし、対応するプローブ結果を提供します。 MTRは、ノードの変更によるテスト結果への影響を防ぎます。 MTRを使用して正確な結果を得ることができます。

Linuxオペレーティングシステムを使用している場合は、mtrパッケージをインストールしてMTRを使用します。 Windowsオペレーティングシステムの場合は、WinMTRを使用できます。次のセクションでは、上記のツールをインストールして使用する方法について説明します。

MTR (Linux)

MTRのインストール

Alibaba Cloud Linux 2またはAlibaba Cloud Linux 3

sudo yum install mtr

CentOS 6、CentOS 7、またはCentOS 8

sudo yum install mtr

UbuntuまたはDebian

sudo apt install mtr

MTRの使用

コマンド構文

mtr [-hvrctglspni46] [-help] [-version] [-report] [-report-cycles=COUNT] [-curses] [-gtk] [-raw] [-split] [-no-dns] [-address interface] [-psize=bytes/-s bytes] [-interval=SECONDS] HOSTNAME [PACKETSIZE]

Parameters

次の表に、一般的なオプションパラメーターを示します。 man mtrコマンドを実行して、他のパラメーターの説明を表示できます。

オプションパラメーター	説明
`-r`または `-report`	MTRをレポートモードに切り替えます。
`-p`または `-split`	分割ユーザーインターフェイスに適した形式で結果を表示するようにMTRを設定します。
`-s`または `-psize`	各pingパケットのサイズを指定します。
`-n`または `-no-dns`	数値IPアドレスを表示するようにMTRを設定し、MTRがホスト名を解決できないようにします。
`-a`または `-address`	パケットの送信元IPアドレスを設定します。説明このパラメーターは、ホストが複数のIPアドレスを持つシナリオで使用できます。
-4	IPv4のみを使用します。
-6	IPv6のみを使用します。

mtrコマンドを実行すると、オペレーティングシステムは自動的にインタラクティブモードになります。このモードでは、パラメータを使用してMTRの動作をすばやく制御したり、表示モードを変更したりできます。下表に、各パラメーターを説明します。

パラメーター	説明
`?` または`h`	コマンドライン引数オプションの概要を表示します。
`d`	表示モードを変更します。
`n`	ドメインネームシステム (DNS) 解決を有効または無効にします。
`u`	探索にインターネット制御メッセージプロトコル (ICMP) パケットまたはUDPパケットを使用します。

サンプルmtrコマンド出力

たとえば、mtr <Destination IP address> コマンドを実行すると、次のコマンド出力が表示されます。

次の表に、デフォルト設定に基づくコマンド出力のパラメーターを示します。

パラメーター	説明
ホスト	ノードのIPアドレスまたはドメイン名。 `n`キーを押すと、表示モードを変更できます。
損失 %	ノードのパケット損失率。
Snt	送信されるパケットの数。デフォルト値は 10 です。 `-c`パラメーターを使用して値を指定できます。
最後	前のプローブのレイテンシ。
平均	すべてのプローブの平均レイテンシ。
ベスト	すべてのプローブの最低レイテンシ。
ラスト	すべてのプローブの中で最も高いレイテンシ。
StDev	ノードのレイテンシの標準偏差。値が高いほど、ノード上のデータパケットの応答時間の差が大きいことを示す。

WinMTR (Windows)

WinMTRのインストール

WinMTRパッケージをダウンロードした後、WinMTRをインストールする必要はありません。パッケージを解凍した後、WinMTRを起動できます。以下の手順を実行します。

WinMTRをWinMTR公式サイトからダウンロードします。
WinMTRパッケージを解凍し、WinMTR.exeをダブルクリックしてWinMTRを起動します。

WinMTRの使用

WinMTRウィンドウで、[ホスト] フィールドに宛先サーバーのIPアドレスまたはドメイン名を入力します。

重要

指定されたIPアドレスまたはドメイン名にスペースを含めることはできません。

他の機能またはパラメータを設定できます。次の表に、機能とパラメーターを示します。

特徴またはパラメータ	説明
テキストをクリップボードにコピー	テスト結果をテキストとしてクリップボードにコピーします。
HTMLをクリップボードにコピー	テスト結果をHTML形式でクリップボードにコピーします。
テキストのエクスポート	テスト結果をテキスト形式のファイルにエクスポートします。
HTMLのエクスポート	テスト結果をHTML形式のファイルにエクスポートします。
オプション	以下を含むオプションのパラメータ: 間隔 (秒): プローブ間の間隔。デフォルト値：1 単位は秒です。 Pingサイズ (バイト): pingプローブに使用される各パケットのサイズ。デフォルト値: 64。単位はバイトです。マックス LRUリスト内のホスト: LRUリスト上のホストの最大数。デフォルト値: 128 名前の解決: ノードのIPアドレスではなく、ノードのドメイン名を表示するように指定します。

[開始] をクリックしてテストを実行します。
テストの開始後、[開始] は [停止] に変わり、WinMTRはテスト結果を表示します。
WinMTRが実行されるのをしばらく待ち、[停止] をクリックしてテストを停止します。

WinMTRによって返されたサンプルテスト結果

たとえば、送信先サーバーのドメイン名をWinMTRで使用してテストを実行する場合、次のテスト結果が表示されます。

测试进行中

次の表に、デフォルト設定に基づくテスト結果のパラメーターを示します。

パラメーター	説明
ホスト名	ノードのIPアドレスまたはドメイン名。
Nr	ノードの番号。
損失 %	ノードのパケット損失率。
送信済み	送信されるパケットの数。
Recv	受信されたパケットの数。
ベスト	すべてのプローブの最低レイテンシ。
平均	すべてのプローブの平均レイテンシ。
最悪	すべてのプローブの中で最も高いレイテンシ。
最後	前のプローブのレイテンシ。
StDev	ノードのレイテンシの標準偏差。値が高いほど、ノード上のデータパケットの応答時間の差が大きいことを示す。

テスト結果の分析

mtrコマンドは高い精度を提供します。このセクションでは、mtrコマンドによって返されるテスト結果の分析について説明します。次の図は、mtrコマンドの出力例を示しています。

ネットワーク

ほとんどの場合、クライアントから宛先サーバーへのネットワークパスは、次のネットワークを通過します。ネットワークの詳細およびネットワークの問題をトラブルシューティングする方法の提案については、次のセクションを参照してください。

ローカルネットワークのクライアント
クライアントのローカルネットワークは、前の図の領域aに示すように、LANとローカルキャリアのネットワークで構成されます。
- LAN内のノードで例外が発生した場合は、LANを確認して例外のトラブルシューティングを行います。
- ローカルキャリアのネットワーク内のノードで例外が発生した場合、ローカルキャリアに例外を報告します。
キャリアネットワーク
ネットワークパスは、前の図の領域Bに示すように、複数のキャリアのバックボーンネットワークを介して移動します。キャリアネットワークのノードで例外が発生した場合、ノードのIPアドレスを照会して、IPアドレスが属するキャリアを特定できます。その後、トラブルシューティングのために、キャリアまたはAlibaba Cloudのアフターサービスにお問い合わせください。
宛先サーバのローカルネットワーク
宛先サーバは、前の図の領域Cに示されるように、キャリアのネットワーク内に存在する。宛先サーバーのローカルネットワーク内のノードで例外が発生した場合は、キャリアに例外を報告します。

説明

ネットワークパス上の特定の中間ノードの負荷が均衡している場合、mtrコマンドは、開始ノードおよび終了ノードのみのMTRデータを番号付け、プローブし、収集する。他のノードの場合、コマンド出力は各ノードのIPアドレスまたはドメイン名情報のみを示します。

メトリックに基づく分析

ネットワークパスの接続性またはパフォーマンスを分析するには、包括的な分析を実行し、パケット損失率 (loss %) 、平均値 (Avg) 、標準偏差 (StDev) 、レイテンシなどのメトリックに基づいて判断します。次のセクションでは、上記のメトリックに基づいてネットワークパスの接続性またはパフォーマンスを分析する方法について説明します。

損失 %

ノードのパケット損失率 (loss %) がゼロでない場合、このホップでネットワーク例外が発生する可能性があります。次の理由により、ノードでパケット損失が発生する可能性があります。

ノードのICMP伝送速度は、セキュリティ目的または性能上の理由から、キャリアによって制限される。
ノードで例外が発生しました。この場合は, 後続ノードでパケットロスが発生したかどうかを確認し, パケットロスの原因を特定してください。
- 後続のノードでパケット損失が発生しなかった場合、ノードでのパケット損失は、前の図の2番目のホップに示すように、キャリアのICMPスロットリングポリシーによって引き起こされます。パケット損失の問題は無視できます。
- 後続のすべてのノードでパケット損失が発生した場合、前の図の6番目のホップに示すように、ノードでネットワーク例外が発生し、パケット損失が発生しました。
- パケット損失が後続のノードのいくつかでのみ発生した場合、ノードのICMP送信レートはキャリアによって制限され、ネットワーク例外がノードで発生します。この場合、自ノード以降のノードで繰り返しパケットロスが発生し、各ノードのパケットロス率が異なる場合には、最後の数ホップのパケットロス率が優先される。前の図に示すように、6、7、8、9番目のホップでパケット損失が発生し、9番目のホップのパケット損失率は30.3% です。 9ホップ目のパケットロス率を参考にする。

AvgとStDev

リンクジッタなどの要因により、ノードのWrst値とBest値は大きく異なる場合があります。 Avgは、MTRテスト開始後のすべてのプローブの平均レイテンシを示し、ノードのネットワーク品質を反映します。より高いStDev値は、ノード上のデータパケットの待ち時間間のより大きな差を示し、データパケットはノード上でより離散的であることを示す。 StDevは、Avg値がノードのネットワーク品質を反映するかどうかを判断するのに役立ちます。例えば、StDev値が高い場合、パケットの待ち時間は不確実である。特定のパケットは、25ミリ秒などの低レイテンシで送信され得、他のパケットは、350ミリ秒などの高レイテンシで送信され得る。この場合、最終的なAvg値は正常範囲内であってもよい。このシナリオでは、Avg値は実際のネットワーク品質を反映していません。

Avg値とStDev値を次の項目に基づいて分析することを推奨します。

ノードのStDev値が高い場合は、ノードのBest値とWrst値を確認して、ノードでネットワーク問題が発生したかどうかを判断します。
ノードのStDev値が高くない場合、ノードのAvg値に基づいてノードでネットワーク問題が発生したかどうかを判断します。
説明
ノードのStDev値が高いかどうかを判断するために、時間範囲標準を使用することはできません。ノードの他のレイテンシ値に基づいて、ノードのStDev値が高いかどうかを判断できます。例えば、Avg値が30 msであり、StDev値が25 msである場合、StDev値は高いと判定される。 Avg値が325 ms、StDev値が25 msである場合、StDev値は高くないと判定される。

レイテンシ

ホップでの遅延スパイク
ホップ後にレイテンシが急上昇すると、そのホップのノードでネットワーク例外が発生します。前の図に示すように、6番目のホップの後にレイテンシが急上昇しました。ホップのノードでネットワーク例外が発生しました。高いレイテンシは、例外がノードで発生したことを示すものではありません。上の図に示すように、6番目のホップの後にレイテンシが急増した場合でも、テストデータは宛先ホストに到達しました。高いレイテンシは、応答パス上でも発生する可能性があります。問題を分析するには、リバースパステストを実行することを推奨します。
ICMPスロットリングによるレイテンシの増加
ノード上のICMPスロットリングはまた、ノード上のレイテンシを増加させるが、後続のノード上のレイテンシには影響しない。前の図に示すように、9番目のホップでのパケット損失率は30% に達し、ホップで待ち時間スパイクが発生しました。後続のノードのレイテンシはすぐに通常レベルに減少しました。ノードでのレイテンシスパイクとパケット損失は、ICMPスロットリングが原因であると結論付けることができます。

サンプル分析と結論

前の図に示すパステストの結果と、メトリックベースの分析の説明に基づいて、次の結論を得ることができます。

クライアントのローカルネットワークでは、2、6、7、8、9ホップ目でパケット損失が発生したが、3、4、5、10、11、15ホップ目ではパケット損失が深刻ではない。ネットワーク内のサービス要求に例外が発生しない場合、2番目、6番目、7番目、8番目、および9番目のホップでのパケット損失がICMPスロットリングによって引き起こされる可能性があります。
第4ホップのWrst値は比較的高いが、ホップのAvg値は高くなく、これは、ネットワーク変動またはプローブにおけるデバイス性能変動によって引き起こされる瞬間的なネットワーク経路変動を示し得る。
ネットワークパス内のすべてのノードの平均レイテンシは1.8 ms〜17.6 msであり、これはネットワークパスのネットワークレイテンシが低いことを示しています。

上記の結論に基づいて、ネットワークパスで例外が発生していないと判断できます。実際のビジネスネットワークにネットワーク変動がある場合は、フォワードパステストの結果に加えて、リバースパステストの結果を分析できます。

説明

ネットワークパスのテスト結果を柔軟に分析できます。上記の分析は、メトリックを分析するための一般的な方法のみを提供します。ネットワークパステストの結果を分析するときは、実際のビジネスシナリオに基づいて包括的な評価を実行する必要があります。このようにして、正確な結論を得ることができます。一方向ネットワークパステストで明確な結論が得られない場合は、リバースネットワークパステストを実行して、問題を詳細に分析および特定できます。

パス例外の一般的なシナリオ

説明

このセクションでは、ネットワークパスで例外が発生する一般的なシナリオについて説明します。この例では、mtrコマンドはLinuxオペレーティングシステムで実行されます。返されるテスト結果は、オペレーティングシステムとテストツールによって異なります。

送信先ホストのネットワークの誤構成

この例では、前の図に示すように、すべてのパケットがデータ送信の終わりに失われます。 ICMPは、ファイアウォールポリシーやiptablesポリシーなど、宛先サーバーのセキュリティポリシーで無効にすることができます。その結果、宛先ホストは応答を送信することができず、パケットは宛先IPアドレスに到達することができない。移行先サーバーのセキュリティポリシーを確認する必要があります。

ICMPスロットル

この例では、前の図に示すように、すべてのパケットがデータ送信の終わりに失われます。 ICMPは、ファイアウォールポリシー、iptablesポリシー、またはキャリアのスロットリングポリシーなど、宛先サーバーのセキュリティポリシーで無効にすることができます。その結果、宛先ホストは応答を送信することができず、パケットは宛先IPアドレスに到達することができない。ターゲットサーバーのセキュリティポリシーを確認するか、リバースパステストを実行して問題を分析する必要があります。

ループ

この例では、前の図に示すように、パケットが5番目のホップを通過した後にルーティングループが発生し、パケットが宛先サーバーに到達できませんでした。ほとんどの場合、ルーティングループは、キャリアノードのルート構成における例外によって引き起こされる。問題を解決するには、キャリアに連絡する必要があります。

ノード中断

次の図に示すように、パケットは4番目のホップを通過するとフィードバックを受信できません。損失 % 、Last、Avg、Bestなどのメトリックには、統計情報は表示されません。ほとんどの場合、この問題はホップでのノードの中断が原因で発生します。問題をトラブルシューティングするには、リバースパステストを実行することを推奨します。ノードが属するキャリアに連絡する必要があります。