TracerouteとMTRを使用してネットワークの問題を診断する方法
序章
サーバー管理の重要な部分は、ネットワーク接続の監視です。
使い方は簡単ですが、知っておく価値のあるツールがいくつかあります。 このガイドでは、tracerouteというツールを使用して、ネットワークの問題が発生している可能性のある場所を診断する方法について説明します。
また、pingとtracerouteの機能の多くを1つのインターフェイスに組み合わせたmtrというユーティリティについても説明します。
Tracerouteの使用方法
tracerouteは、リモートサーバーへの経路を表示するためのシンプルなツールです。 これは、アクセスしようとしているWebサイトから、ローカルネットワーク上のプリンターまで何でもかまいません。
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ユーティリティを使用すると、より広範囲の時間にわたってデータを収集することにより、この状況を監視できます。
--reportオプションを指定してmtrを実行することもできます。これにより、各ホップに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に情報を提供しようとする場合に役立ちます。
