TracerouteとMTRを使用してネットワークの問題を診断する方法
序章
サーバー管理の重要な部分は、ネットワーク接続の監視です。
使い方は簡単ですが、知っておく価値のあるツールがいくつかあります。 このガイドでは、と呼ばれるツールの使用方法について説明します traceroute ネットワークの問題が発生している可能性のある場所を診断します。
また、というユーティリティについても見ていきます。 mtr これは、pingとtracerouteの機能の多くを1つのインターフェイスに統合します。
Tracerouteの使用方法
traceroute は、リモートサーバーへの経路を示すためのシンプルなツールです。 これは、アクセスしようとしているWebサイトから、ローカルネットワーク上のプリンターまで何でもかまいません。
The traceroute プログラムはデフォルトでほぼすべてのLinuxディストリビューションにインストールされるため、インストールする必要はありません。
それを呼び出すには、調査したいWebサイトまたはIPアドレスを提供する必要があります。
- traceroute google.com
次のような出力が表示されます。
Outputtraceroute to google.com (173.194.38.137), 30 hops max, 60 byte packets
1 192.241.160.253 (192.241.160.253) 0.564 ms 0.539 ms 0.525 ms
2 192.241.164.241 (192.241.164.241) 0.487 ms 0.435 ms 0.461 ms
3 xe-3-0-6.ar2.nyc3.us.nlayer.net (69.31.95.133) 1.801 ms 1.802 ms 1.762 ms
4 144.223.28.73 (144.223.28.73) 0.583 ms 0.562 ms 0.550 ms
5 144.232.1.21 (144.232.1.21) 1.044 ms 1.048 ms 1.036 ms
6 74.125.49.212 (74.125.49.212) 0.494 ms 0.688 ms 0.643 ms
7 209.85.248.180 (209.85.248.180) 0.650 ms 209.85.248.178 (209.85.248.178) 0.621 ms 0.625 ms
8 72.14.236.208 (72.14.236.208) 0.618 ms 72.14.236.206 (72.14.236.206) 0.898 ms 72.14.236.208 (72.14.236.208) 0.872 ms
9 72.14.239.93 (72.14.239.93) 7.478 ms 7.989 ms 7.466 ms
10 72.14.232.73 (72.14.232.73) 20.002 ms 19.969 ms 19.975 ms
11 209.85.248.228 (209.85.248.228) 30.490 ms 72.14.238.106 (72.14.238.106) 34.463 ms 209.85.248.228 (209.85.248.228) 30.707 ms
12 216.239.46.54 (216.239.46.54) 42.502 ms 42.507 ms 42.487 ms
13 216.239.46.159 (216.239.46.159) 76.578 ms 74.585 ms 74.617 ms
14 209.85.250.126 (209.85.250.126) 80.625 ms 80.584 ms 78.514 ms
15 72.14.238.131 (72.14.238.131) 80.287 ms 80.560 ms 78.842 ms
16 209.85.250.228 (209.85.250.228) 171.997 ms 173.668 ms 170.068 ms
17 66.249.94.93 (66.249.94.93) 238.133 ms 235.851 ms 235.479 ms
18 72.14.233.79 (72.14.233.79) 233.639 ms 239.147 ms 233.707 ms
19 sin04s01-in-f9.1e100.net (173.194.38.137) 236.241 ms 235.608 ms 236.843 ms
最初の行は、tracerouteが動作している条件を示しています。
Outputtraceroute to google.com (173.194.38.137), 30 hops max, 60 byte packets
指定されたホスト、DNSがそのドメインに対して返すIPアドレス、チェックする最大ホップ数、および使用されるパケットのサイズを提供します。
最大ホップ数は、 -m 国旗。 ルーティングしようとしているホストが30ホップ以上離れている場合は、ここでより大きな値を指定する必要があります。 設定できる最大値は255です。
- traceroute -m 255 obiwan.scrye.net
ホスト名の後に整数を指定することで、各ホップに送信されるパケットのサイズを調整できます。
- traceroute google.com 70
次のような出力が表示されます。
Outputtraceroute to google.com (173.194.38.128), 30 hops max, 70 byte packets
1 192.241.160.254 (192.241.160.254) 0.364 ms 0.330 ms 0.319 ms
2 192.241.164.237 (192.241.164.237) 0.284 ms 0.343 ms 0.321 ms
最初の行の後の各行は、指定したホストで表されるコンピューターに到達するためにトラフィックが通過する必要のある「ホップ」または中間ホストを表します。
各行の形式は次のとおりです。
Outputhop_number host_name (IP_address) packet_round_trip_times
表示される可能性のあるホップの例を次に示します。
Output3 nyk-b6-link.telia.net (62.115.35.101) 0.311 ms 0.302 ms 0.293 ms
各フィールドの意味は次のとおりです。
- hop_number ：ホストがコンピューターから分離している度合いの連続カウント。 番号の大きいホストからのトラフィックは、ルーティングされるためにより多くのコンピューターを通過する必要があります。
- host_name ：このフィールドには、ホストのIPアドレス（使用可能な場合）でのDNS逆引き参照の結果が含まれます。 逆引きDNSクエリから情報が返されない場合は、IPアドレス自体が指定されます。
- IP_address ：このフィールドには、このネットワークホップのIPアドレスが含まれます。
- packet_round_trip_times ：行の残りの部分は、パケットがホストに行き、また戻ってくるまでのラウンドトリップ時間を示します。 デフォルトでは、3つのパケットが各ホストに送信され、各試行は行の最後に追加されます。
各ホストに対してテストされるパケットの数を変更する場合は、で数を指定できます。 -q このようなオプション：
- traceroute -q1 google.com
トレースを高速化するために逆引きDNSルックアップを放棄したい場合は、 -n 国旗：
- traceroute -n google.com
次のような出力が得られます。
Outputtraceroute to google.com (74.125.235.7), 30 hops max, 60 byte packets
1 192.241.160.253 0.626 ms 0.598 ms 0.588 ms
2 192.241.164.241 2.821 ms 2.743 ms 2.819 ms
3 69.31.95.133 1.470 ms 1.473 ms 1.525 ms
tracerouteがいくつかのアスタリスク（*）に溶け込んでいる場合は、ホストへのルートに問題があります。
Output...
15 209.85.248.220 (209.85.248.220) 121.809 ms 72.14.239.12 (72.14.239.12) 76.941 ms 209.85.248.220 (209.85.248.220) 78.946 ms
16 72.14.239.247 (72.14.239.247) 101.001 ms 92.478 ms 92.448 ms
17 * * 209.85.250.124 (209.85.250.124) 175.083 ms
18 * * *
19 * * *
ルートの問題はどういう意味ですか？
tracerouteの試行が特定のホップまたはノードで停止し、ホストへのルートが見つからない場合は、問題があります。
ルートが戻らないホップがネットワークの問題の場所である可能性がありますが、診断が必ずしも簡単であるとは限りません。
各pingはラウンドトリップパケットを表すという事実と、パケットがどちらの方向にも異なる経路を使用することが多い状況のため、完全に異なる、場合によってはより近いルートに問題があることを示している可能性があります。
最後のホップの直後のホップに問題がある場合もあります。 その特定のホップからリターンtracerouteを取得できない限り、問題の正確な場所を診断することは困難です。 これは通常、独自のネットワークの外部では不可能です。
MTRの使用方法
tracerouteプログラムの動的な代替手段は次のとおりです。 mtr. mtrを使用すると、pingとtracerouteの機能を組み合わせて、リモートサーバーを常にポーリングし、遅延とパフォーマンスが時間の経過とともにどのように変化するかを確認できます。
tracerouteとは異なり、mtrはほとんどのシステムにデフォルトでインストールされていません。 次のコマンドを入力すると取得できます。
Ubuntu / Debian：
- sudo apt-get install mtr
CentOS / Fedora：
- yum install mtr
アーチ：
- pacman -S mtr
インストールしたら、次のように入力して呼び出すことができます。
- mtr google.com
次のような出力を受け取ります。
Output My traceroute [v0.80]
traceroute (0.0.0.0) Tue Oct 22 20:39:42 2013
Resolver: Received error response 2. (server failure)er of fields q
uit Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.241.160.253 0.0% 371 0.4 0.6 0.1 14.3 1.0
2. 192.241.164.241 0.0% 371 7.4 2.5 0.1 37.5 4.8
3. xe-3-0-6.ar2.nyc3.us. 2.7% 371 3.6 2.6 1.1 5.5 1.1
4. sl-gw50-nyc-.sprintli 0.0% 371 0.7 5.0 0.1 82.3 13.1
出力は似ているように見えるかもしれませんが、tracerouteに対する大きな利点は、出力が常に更新されることです。 これにより、傾向と平均を蓄積でき、ネットワークパフォーマンスが時間の経過とともにどのように変化するかを確認することもできます。
tracerouteを実行した場合、ルートが断続的にパケット損失を被っている状況でも、各ホップに送信されたパケットが問題なくトリップした可能性があります。 mtrユーティリティを使用すると、より広範囲の時間にわたってデータを収集することにより、この状況を監視できます。
でmtrを実行することも可能です --report オプション。各ホップに10個のパケットを送信した結果を返します。
- mtr --report google.com
レポートは次のようになります。
OutputHOST: traceroute Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.241.160.254 0.0% 10 1.5 0.9 0.4 1.5 0.4
2.|-- 192.241.164.237 0.0% 10 0.6 0.9 0.4 2.7 0.7
3.|-- nyk-b6-link.telia.net 0.0% 10 0.5 0.5 0.2 0.7 0.2
4.|-- nyk-bb2-link.telia.net 0.0% 10 67.5 18.5 0.8 87.3 31.8
これは、必ずしもリアルタイムで測定する必要はないが、tracerouteが提供するよりも広い範囲のデータが必要な場合に役立ちます。
結論
と traceroute と mtr、特定のドメインまたはアドレスに向かう途中のどのサーバーが問題を引き起こしているのかを把握できます。 これは、内部ネットワークのトラブルシューティングを行う場合や、ネットワークの問題が発生しているときにサポートメンバーまたはISPに情報を提供しようとする場合に役立ちます。
