クライアントがターゲットサーバーにアクセスするときに、pingパケットロスが発生したり、サーバーにpingができない場合は、traceroute (または TRACERT)やMTR (または WinMTR)などのツールを使用してリンクをテストし、問題を特定できます。この記事では、リンクテストツール、テスト結果の分析、テスト手順について説明します。
リンクテストツールの概要
リンクテストツールは、OS の種類によって異なります。ここでは、Windows と Linux のリンクテストツールについてそれぞれ説明していきます。
Linuxのリンクテストツールの概要
tracerouteコマンドラインツール
tracerouteは、ほぼすべてのバージョンのLinuxに事前にインストールされているネットワークテストツールです。このツールは、インターネットプロトコル (IP) を使用してデータパケットをターゲットの IP アドレスに転送するパスを追跡するために使用します。
traceroute はまず最大生存期間 (TTL) (Max_TTL) が短い UDP テストパケットを送信した後に、ゲートウェイから始まるリンク全体で ICMP TIME_EXCEEDED 応答をリッスンします。TTL=1 になるとテストが開始され、ICMP PORT_UNREACHABLE メッセージを受信するまでは TTL 値が増えていき、継続されます。ICMP PORT_UNREACHABLE メッセージは、ターゲットのホストが特定されたこと、またはコマンドを実行するときにデータパケットの転送パスを追跡するための最大 TTL 値に到達していることを確認するために使用されます。
デフォルトでは、traceroute は UDP データパケットをリンクテスト用に送信します。-I パラメーターを設定すると、traceroute では ICMP データパケットがリンクテスト用に送信されます。
使用方法:
traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] [ -s SRC_Addr ] [ -t TypeOfService ] [ -f flow ] [ -v ] [ -w WaitTime ] Host [ PacketSize ]
サンプル出力：
[root@centos ~]# traceroute -I 223.5.5.5traceroute to 223.5.5.5 (223.5.5.5), 30 hops max, 60 byte packets1 * * *2 192.168.17.20 (192.168.17.20) 3.965 ms 4.252 ms 4.531 ms3 111.1.20.41 (111.1.20.41) 6.109 ms 6.574 ms 6.996 ms4 111.1.34.197 (111.1.34.197) 2.407 ms 2.451 ms 2.533 ms5 211.138.114.25 (211.138.114.25) 1.321 ms 1.285 ms 1.304 ms6 211.138.114.70 (211.138.114.70) 2.417 ms 211.138.114.66 (211.138.114.66) 1.857 ms 211.138.114.70 (211.138.114.70) 2.002 ms7 42.120.244.194 (42.120.244.194) 2.570 ms 2.536 ms 42.120.244.186 (42.120.244.186) 1.585 ms8 42.120.244.246 (42.120.244.246) 2.706 ms 2.666 ms 2.437 ms9 * * *10 public1.alidns.com (223.5.5.5) 2.817 ms 2.676 ms 2.401 ms
共通パラメーターの説明:
| パラメータ | 説明 |
|---|---|
| -d | Socket 層のトラブルシューティング機能を有効にするために使用します。 |
| -f | 最初のテストパケットの TTL 値を設定するために使用します。 |
| -F | セグメント識別子を表示しないことを指定するために使用します。 |
| -g | ソースルーティングゲートウェイを設定するために使用します。最大 8 つのソースルーティングゲートウェイを設定できます。 |
| -i | データパケットを送信するネットワークアダプターを指定するために使用します。このパラメーターは、ホストに複数のネットワークアダプターがある場合に使用します。 |
| -I | UDP データパケットをリンクテスト用に ICMP データパケットに置き換えるために使用します。 |
| -m | テストパケットの最大 TTL 値を設定するために使用します。 |
| -n | ホスト名ではなく (逆引き DNS ルックアップを無効にして) IP アドレスを直接使用できるようにするために使用します。 |
| -p | UDP 通信ポートを設定するために使用します。 |
| -r | 一般的なルーティングテーブルを無視し、データパケットをリモートホストに直接送信できるようにするために使用します。 |
| -s | ローカルホストから送信されたデータパケットの IP アドレスを設定するために使用します。 |
| -t | テストパケットの TOS 値を設定するために使用します。 |
| -v | コマンドの実行プロセスの詳細を表示するために使用します。 |
| -w | データパケットの受信についてリモートホストからの応答の返信を待機する期間を設定するために使用します。 |
| -x | パケット正確性テストを有効または無効にするために使用します。 |
Windowsのリンクテストツールの概要
TRACERT コマンドラインツール
TRACERT (または Trace Route) は、ネットワーク診断用の Windows コマンドラインユーティリティです。 これは、ターゲットの IP アドレスに送信される IP データパケットのパスを追跡するために使用されます。
TRACERT は、ICMP データパケットを送信して、ターゲットアドレスへのルートを判断します。これらのデータパケットで、TRACERT は、IP アドレスの異なる TTL 値を使用します。データパケット転送パスをたどるルーターは、データパケットを転送する前に少なくとも TTL を 1 減らす必要があるため、TTL は実際にはホップカウンターと同じになります。パケットの TTL がゼロ (0) に達すると、対応するノードから送信元のコンピューターに ICMP “timeout“ メッセージが送信されます。
TRACERT はまず TTL 値が 1 のパケットを送信し、TTL 値を 1 ずつ増やしていき、送信先が応答するまでまたは最大 TTL 値に達するまで、以降の各送信で対応するパケットを送信します。中間ルーターから返される ICMP “timeout“ メッセージには、対応するノードの情報が含まれます。
使用方法:
mtr [-hvrctglspni46] [--help] [--version] [--report][--report-cycles=COUNT] [--curses] [--gtk][--raw] [--split] [--no-dns] [--address interface][--psize=bytes/-s bytes][--interval=SECONDS] HOSTNAME [PACKETSIZE]
サンプル出力:
[root@centos ~]# traceroute -I 223.5.5.5My traceroute [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 23:16:27 2016Keys: Help Display mode Restart statistics Order of fields quitPackets PingsHost Loss% Snt Last Avg Best Wrst StDev1\. ???2\. 192.168.17.20 0.0% 7 13.1 5.6 2.1 14.7 5.73\. 111.1.20.41 0.0% 7 3.0 99.2 2.7 632.1 235.44\. 111.1.34.197 0.0% 7 1.8 2.0 1.2 2.9 0.65\. 211.138.114.25 0.0% 6 0.9 4.7 0.9 13.9 5.86\. 211.138.114.70 0.0% 6 1.8 22.8 1.8 50.8 23.6211.138.128.134211.138.114.2211.138.114.667\. 42.120.244.186 0.0% 6 1.4 1.6 1.3 1.8 0.242.120.244.1988\. 42.120.244.246 0.0% 6 2.8 2.9 2.6 3.2 0.242.120.244.2429\. ???10\. 223.5.5.5 0.0% 6 2.7 2.7 2.5 3.2 0.3
共通パラメーターの説明:
| パラメータ | 説明 |
|---|---|
| -r | レポートに出力情報を表示するために使用されます。 |
| --report | |
| -p | トラッキング結果を毎回明確にリストするために使用します。これは、すべての結果を提供する —report とは異なります。 |
| --split | |
| -s | ping データパケットのサイズを指定するために使用します。 |
| --split | |
| -n | 引きドメイン名解決の実行に IP アドレスを使用しないことを指定するために使用します。 |
| --no-dns | |
| -a | データパケット送信用の IP アドレスを設定するために使用します。このパラメーターは、ホストに複数の IP アドレスがある場合に使用します。 |
| --address | |
| -4 | IPv4 のみを使用することを指定するために使用します。 |
| -6 | IPv6 のみを使用することを指定するために使用します。 |
また、MTR を使用するときは、1 文字入力して別のモードにすばやく切り替えることができます。次に例を示します。
| パラメータ | 説明 |
|---|---|
| ? | ヘルプメニューを表示するために使用します。 |
| h | ヘルプメニューを表示するために使用します。 |
| d | 表示モードの切り替えに使用します。 |
| n | 解決を有効または無効にするために使用します。 |
| u | リンクですとでの、ICMPまたはUDPのデータパケットの使用を切り替えるために使用します。 |
リターン結果の説明：
次の表ではデフォルト構成における戻り値の各々の列を示しています。
| パラメータ | 説明 |
|---|---|
| Col 1: Host | ノードの IP アドレスとドメイン名。前に説明したように、英文字 n を入力すると、IP アドレスとドメイン名の表示を切り替えることができます。 |
| Col 2: Loss% | ノードのパケットロス率。 |
| Col 3: Snt | 1 秒に送信されるデータパケットの数。デフォルト値は 10 です。これは、-c パラメーターで指定できます。 |
| Col 4: Last | 最新のテストのレイテンシ値。 |
| Col 5: Avg | レイテンシの平均値です。 |
| Col 6: Best | レイテンシの最小値です。 |
| Col 7: Wrst | レイテンシの最大値です。 |
| Col 8: StDev | 標準偏差。標準偏差が高い場合、より不安定なノードを示します。 |
Windowsのリンクテストツールの概要
TRACERT コマンドラインツール
TRACERT (または Trace Route) は、ネットワーク診断用の Windows コマンドラインユーティリティです。 これは、ターゲットの IP アドレスに送信される IP データパケットのパスを追跡するために使用されます。
TRACERT は、ICMP データパケットを送信して、ターゲットアドレスへのルートを判断します。これらのデータパケットで、TRACERT は、IP アドレスの異なる TTL 値を使用します。データパケット転送パスをたどるルーターは、データパケットを転送する前に少なくとも TTL を 1 減らす必要があるため、TTL は実際にはホップカウンターと同じになります。パケットの TTL がゼロ (0) に達すると、対応するノードから送信元のコンピューターに ICMP “timeout“ メッセージが送信されます。
TRACERT はまず TTL 値が 1 のパケットを送信し、TTL 値を 1 ずつ増やしていき、送信先が応答するまでまたは最大 TTL 値に達するまで、以降の各送信で対応するパケットを送信します。中間ルーターから返される ICMP “timeout“ メッセージには、対応するノードの情報が含まれます。
使用方法:
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name
サンプル出力:
C:\> tracert -d 223.5.5.5Use at most 30 hops to track the routes of 223.5.5.5.1 * * * Request timeout.2 9 ms 3 ms 12 ms 192.168.17.203 4 ms 9 ms 2 ms 111.1.20.414 9 ms 2 ms 1 ms 111.1.34.1975 11 ms * * 211.140.0.576 3 ms 2 ms 2 ms 211.138.114.627 2 ms 2 ms 1 ms 42.120.244.1908 32 ms 4 ms 3 ms 42.120.244.2389 * * * Request timeout.10 3 ms 2 ms 2 ms 223.5.5.5Tracking is finished.
共通パラメーターの説明:
| パラメータ | 説明 |
|---|---|
| -d | IP アドレスをホスト名に解決しない (逆引きドメイン名解決を無効にする) ことを指定するために使用します。 |
| -h | ターゲットの IP アドレスを検索するときにホップの最大数を指定するために使用します。 |
| maximum_hops | |
| -j | ホストリストに沿った緩やかなソースルートを指定するために使用します。 |
| host-list | |
| -w | 各応答のタイムアウト期間で指定された待機時間 (ミリ秒) を表示するために使用します。 |
| timeout | |
| -R | ラウンドトリップルートを追跡するために使用します (IPv6 の場合のみ)。 |
| -S | 使用するソース IP アドレスを示します (IPv6 の場合のみ)。 |
| srcaddr | |
| -4 | IPv4 のみを使用することを指定するために使用します。 |
| -6 | IPv6 のみを使用することを指定するために使用します。 |
| target_host | ターゲットホストドメイン名または IP アドレスを示します。 |
WinMTR コマンドラインツール (推奨)
WinMTR は、Windows 用のグラフィカル MTR ツールです。ただし、これは簡略化されており、一部の MTR パラメーターのみに対応します。デフォルトでは、WinMTR は ICMP データパケットのみをリンクテスト用に送信します。
WinMTR をその 公式 Web サイトからダウンロードできます。
tracert と比べて、WinMTR は (MTR と同様に) ノード変動の影響を回避するため、テスト結果の精度が高くなります。したがって、WinMTR を使用できる場合は、WinMTR を使用してリンクをテストすることをお勧めします。
使用方法:
WinMTR を解凍すると、インストールなしで起動できます。非常に簡単な操作手順を次に示します。
プログラムが起動した後に、[Host] フィールドにターゲットサーバーのドメイン名または IP アドレスを入力します (注意: ドメイン名または IP アドレスの前にスペースを入力しないでください)。
[Start] をクリックしてテストを開始します (テストが開始されると、[Start] ボタンが [Stop] に変わります)。
- [Stop] をクリックし、しばらくするとテストが停止します。
- その他のオプションについての説明:
- [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 アドレスルックアップによりノードをドメイン名で表示します。
リターン結果の説明:
デフォルト設定で返される結果の各データ列について以下で説明します。
- 列 1 (Hostname): ノードの IP アドレスとドメイン名。
- 列 2 (Nr): ノード番号。
- 列 3 (Loss%): ノードのパケットロス率。
- 列 4 (Sent): 送信されたデータパケット数。
- 列 5 (Recv): 正常に受信したデータパケット数。
- 列 6 ～ 9 (Best、Avg、Worst、および Last): 対応するノードへのレイテンシの最小値、平均値、最大値、および最新値。
- 列 10 (StDev): 標準偏差。標準偏差が高い場合、より不安定なノードを示します。
リンクテスト結果の分析に関する簡単な説明
この記事では、MTR (WinMTR) を使ったリンクテストの結果の精度が高いことを考慮して、MTR (WinMTR) によるリンクテストの結果を例に挙げて簡単な分析を実行します。
分析は、以下に基づいて行われます。リンクテスト結果のサンプル:
リンクテスト結果を分析するときに、以下の点を重視します。
- ネットワークエリア
- リンクのロードバランシング
- Avg(平均値) と StDev (標準偏差) に基づく包括的な評価
- Loss% (パケットロス率) の評価
- レイテンシについて
ネットワークエリア
標準の条件では、クライアントをターゲットサーバーに接続するリンク全体に次のエリアが含まれます。
- クライアントのローカルネットワーク (LAN とローカルネットワークプロバイダーのネットワーク): 上記に示すエリア A . クライアントのローカルネットワークノードのこのエリアで例外が発生した場合は、ローカルネットワークを分析およびトラブルシューティングする必要があります。それ以外で、ローカルネットワークのアクセスプロバイダーのネットワークノードで例外が発生した場合は、ローカルのアクセスプロバイダーに問題を報告する必要があります。
- ターゲットサーバーのローカルネットワーク (ターゲットホストのアクセスプロバイダーのネットワーク): 上記に示すエリア C . このエリアで例外が発生した場合は、問題をターゲットのホストネットワークのアクセスプロバイダーに報告します。
リンクのロードバランシング
上記に示すエリア D . 中間リンクの一部でリンクのロードバランシングが有効になっている場合、MTR は開始ノードと終了ノードのみに番号を付け、それらノードをテストし、それらのノードに関する統計を収集します。中間ノードには、対応する IP アドレスまたはドメイン名のみ表示できます。
Avg (平均値) と StDev (標準偏差) に基づく包括的な評価
リンクジッターまたはその他の要因により、ノードの Best と Worst 値は非常に大きく変わる場合があります。Avg (平均値) は、すべてのリンクテストの平均値に関する統計を収集するため、対応するノードのネットワーク品質がより的確に反映される可能性があります。
StDev (標準偏差) が高い場合は、対応するノードのパケットのレイテンシ値がより離散していることを示します。そのため、標準偏差を使用すると、Avg に対応するノードのネットワーク品質が実際に反映されているかどうかを確認できます。たとえば、標準偏差が大きい場合、データパケットのレイテンシは不明確になります。レイテンシが短い (25 ミリ秒など) データパケットと、長い (350 ミリ秒など) データパケットがありますが、平均のレイテンシが最終的に標準になる場合があります。したがって、Avg 値には実際のネットワーク品質が適切に反映されません。
まとめると、推奨される分析基準は次のようになります。
- StDev 値が大きい場合は、対応するノードの Best と Wrst 値も大きいか確認して、ノードで例外が発生しているかどうかを判断します。
- StDev 値が大きくない場合は、Avg 値を使用してノードで例外が発生しているかどうかを判断します。注意: StDev 値が “大きい“ か “大きくない“ かを判断する特定の時間範囲や基準はありません。StDev 値が大きいかどうかは、同じノードの他の列にリストされているレイテンシ値に基づいて評価されます。たとえば、Avg 値が 30 ミリ秒の場合、25 ミリ秒の StDev 値は大きな標準偏差値と見なされます。一方、Avg 値が 325 ミリ秒の場合、同じ 25 ミリ秒の StDev 値は大きな標準偏差値と見なされません。
Loss%(パケットロス率)の評価
ノードの Loss% (パケットロス率) がゼロでない場合は、ネットワークのこのホップで例外が発生している可能性があります。通常、パケットロスは次のいずれかの理由によりノードで発生します。
- アクセスプロバイダーが、セキュリティまたはパフォーマンス要件に基づいてノードの ICMP 送信レートを手動で制限しているために、パケットロスが発生します。
- 例外がノードで発生した結果、パケットロスが発生します。
例外が発生しているノードの後続のノードで問題が繰り返されるかどうかに基づいて、パケットロスの理由を特定できます。
- 後続のノードでパケットロスが発生しない場合は、通常、例外ノードのパケットロスはアクセスプロバイダーの速度制限ポリシーが原因になっていることを示し、上記の 2 番目のホップに示すようにパケットロスは無視できます。リンクテスト結果のサンプル.
- 後続のノードでもパケットロスが発生する場合は、通常、ノードでネットワーク例外が発生していることが原因であることを示し、上記の 5 番目のホップに示すようにパケットロスが発生しています。リンクテスト結果のサンプル。
また、両方が同時に原因となっている可能性もあることに注意してください。つまり、速度制限ポリシーとネットワークの例外が原因となって、対応するノードでパケットロスが生じます。このケースでは、パケットロスが例外ノードと後続のノードで連続して発生し、パケットロス率がノードごとに異なる場合、通常は、最後の数ホップのパケットロス率が適用されます。たとえば、上記のリンクテスト結果のサンプルでは、5 番目、6 番目、および 7 番目のホップでパケットロスが発生しています。したがって、7 番目のホップの 40% のパケットロスが、参照用に適用されます。
レイテンシの急増
特定のホップの後にレイテンシが急増する場合は、通常、このノードのネットワーク例外を示します。たとえば、上記のでは、5 番目のホップの後にレイテンシが急増しており、5 番目のホップのノードでネットワークの例外が発生していることを示しています。
ただし、レイテンシが長い場合、必ずしも対応するノードで例外が発生しているとは限りません。たとえば、上記のリンクテスト結果のサンプルでは、ノードの 5 番目のホップの後にレイテンシが急増していますが、テスト結果のデータは最終的に通常どおりホストに到達しています。したがって、長いレイテンシは、データパケットを受信するための応答が返信されたときにもリンクで生じる可能性があります。このため、問題を解決するためにリンクを逆方向にテストすることをお勧めします。
ICMP 制限速度により延長されるレイテンシ
ICMP 制限速度ポリシーが原因でレイテンシが急増する場合もありますが、通常、後続のノードではレイテンシは正常な状態になります。たとえば、上記のでは、3 番目のホップのパケットロス率は 100% で、その間にレイテンシが急増しています。ただし、レイテンシは後続のノードで正常になります。したがって、速度制限ポリシーがノードでのレイテンシ急増とパケットロスの原因であると判断できます。
一般的なリンクの例外シナリオとテストレポート
一般的なリンクの例外シナリオとテストレポートについて、以下で説明します。
- ターゲットのホストネットワークの不適切な設定
- ICMP制限速度
- ループ
- リンクの中断
データのサンプル:
root@mycentos6 ~]# mtr --no-dns www.google.comMy traceroute [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016Keys: Help Display mode Restart statistics Order of fields quitPackets PingsHost Loss% Snt Last Avg Best Wrst StDev1\. ???2\. ???3\. 111.1.20.41 0.0% 10 521.3 90.1 2.7 521.3 211.34\. 111.1.34.209 0.0% 10 2.9 4.7 1.6 10.6 3.95\. 211.138.126.29 80.0% 10 3.0 3.0 3.0 3.0 0.06\. 221.183.14.85 0.0% 10 1.7 7.2 1.6 34.9 13.67\. 221.183.10.5 0.0% 10 5.2 5.2 5.1 5.2 0.0221.183.11.58\. 221.183.23.26 0.0% 10 5.3 5.2 5.1 5.3 0.19\. 173.194.200.105 100.0% 10 0.0 0.0 0.0 0.0 0.0
この例では、送信先 IP アドレスで 100% のパケットロスが発生しています。一見、パケットは到達できないように見えますが、実際には、ターゲットサーバーの関連のセキュリティポリシー (ファイアウォールや iptables など) で ICMP が無効になっているため、送信先のホストが応答を送信できない可能性があります。
したがって、このシナリオでは、ターゲットサーバーに設定されているセキュリティポリシーをチェックする必要があります。
ICMP制限速度
データのサンプル:
[root@mycentos6 ~]# mtr --no-dns www.google.comMy traceroute [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016Keys: Help Display mode Restart statistics Order of fields quitPackets PingsHost Loss% Snt Last Avg Best Wrst StDev1\. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32\. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83\. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74\. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.15\. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.96\. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.27\. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.38\. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
この例では、5 番目のホップで明らかなパケットロスが発生していますが、後続のノードで例外は発生していません。そのため、パケットロスはノードの ICMP 速度制限が原因で発生したと推測できます。
このシナリオでは、最後のクライアントからターゲットへのデータ送信は影響を受けないため、そのデータ送信を分析する必要はありません。
ループ
データのサンプル:
[root@mycentos6 ~]# mtr --no-dns www.google.comMy traceroute [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016Keys: Help Display mode Restart statistics Order of fields quitPackets PingsHost Loss% Snt Last Avg Best Wrst StDev1\. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32\. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83\. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74\. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.15\. 72.14.233.56 0.0% 10 0.0 0.0 0.0 0.0 0.06\. 72.14.233.57 0.0% 10 0.0 0.0 0.0 0.0 0.07\. 72.14.233.56 0.0% 10 0.0 0.0 0.0 0.0 0.08\. 72.14.233.57 0.0% 10 0.0 0.0 0.0 0.0 0.09 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
この例では、5 番目のホップの後にループが発生しているため、データパケットは最終的にターゲットサーバーに到達できません。これは通常、アクセスプロバイダーのノードのルーティング設定が正しくないことが原因です。
そのため、ノードを担当しているアクセスプロバイダーに問い合わせて処理してもらう必要があります。
リンクの中断
データのサンプル:
[root@mycentos6 ~]# mtr --no-dns www.google.comMy traceroute [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016Keys: Help Display mode Restart statistics Order of fields quitPackets PingsHost Loss% Snt Last Avg Best Wrst StDev1\. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32\. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83\. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74\. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.15\. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.06\. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.07\. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.08\. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.09 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
この例では、4 番目のホップの後データパケットから応答が受信されていません。これは通常、対応するノードのリンクの中断が原因です。問題を確認するためにリンクを逆方向にテストすることをお勧めします。
ノードを担当しているアクセスプロバイダーに問い合わせて処理してもらう必要があります。
このは、通常の状態でのリンクテスト手順を示しています。
- ローカルネットワークに対応するパブリックネットワークの IP アドレスを取得する
- リンクをテストする (ping コマンドと MTR を使用)
- リンクを逆方向にテストする (ping コマンドと MTR を使用)
- テスト結果を分析する
ローカルネットワークに対応するパブリックネットワークの IP アドレスを取得する
ローカルネットワーク上のクライアントから、以下の図に示す ip.taobao.com などの Web サイトにアクセスし、ローカルネットワークに対応するパブリックネットワークの IP アドレスを取得します。
リンクをテストする (ping コマンドと MTR を使用)ターゲットサーバーを ping するか、MTR を使用してクライアントのリンクをテストします。
- クライアントからターゲットサーバーのドメイン名または IP アドレスを連続して ping し (少なくとも 100 個のデータパケットの ping を推奨)、テスト結果を記録します。
- クライアントの OS に基づいて WinMTR または MTR を使用し、テスト送信先アドレスをターゲットサーバーのドメイン名または IP アドレスに設定します。その後、リンクテストを実行してテスト結果を記録します。
リンクを逆方向にテストする (ping コマンドとMTR を使用)
ターゲットサーバーシステムにアクセスしてクライアントを ping するか、MTR を使用してリンクを逆方向にテストします。
- ターゲットサーバーからステップ 1 で取得したクライアントのドメイン名または IP アドレスを連続して ping し (少なくとも 100 個のデータパケットの ping を推奨)、テスト結果を記録します。
- ターゲットサーバーの OS に基づいて WinMTR または MTR を使用して、テスト送信先アドレスをステップ 1 で取得したクライアントの IP アドレスに設定し、リンクテストを実行して、テスト結果を記録します。
テスト結果を分析する
テスト結果を分析するには、前述の説明を参照してください。例外が発生しているノードを特定した後に、ip.taobao.com などの Web サイトにアクセスし、担当しているアクセスプロバイダーと例外ノードのネットワークを照会して確認します。
クライアントのローカルネットワークノードで例外が発生した場合は、ローカルネットワークを分析およびトラブルシューティングする必要があります。アクセスプロバイダーのノードで例外が発生した場合は、問題を直接担当のアクセスプロバイダーに報告するか、Alibaba Cloud アフターサービステクニカルサポートに連絡して担当のアクセスプロバイダーに問題を報告してもらいます。
その他のリソース
- traceroute(8) - Linux man ページ: traceroute の MAN ヘルプページ。
- 『What is MTR』:BitWizard の MTR に関する説明。
- WinMTR: WinMTR の公式 Web サイト。