web-dev-qa-db-ja.com

tracerouteに複数のパスが表示されるのに、mtrには表示されないのはなぜですか？

ネットワークが複数のパスを使用していることは知っています。これらはtracerouteに表示されますが、mtrには表示されません。 mtrはどういうわけか最初のパスに固執していますか？ドンってなに？

$ traceroute google.com
traceroute to google.com (216.58.210.46), 30 Hops max, 60 byte packets
 1  gateway (172.16.9.1)  1.303 ms  1.332 ms  1.421 ms
 2  Host-92-31-0-1.as13285.net (92.31.0.1)  14.965 ms  15.810 ms  16.978 ms
 3  xe-11-2-0-bragg001.bre.as13285.net (78.151.225.39)  19.456 ms  20.785 ms  23.052 ms
 4  Host-78-151-225-14.static.as13285.net (78.151.225.14)  24.255 ms Host-78-151-229-20.as13285.net (78.151.229.20)  25.979 ms Host-78-151-225-18.static.as13285.net (78.151.225.18)  27.059 ms
 5  Host-78-144-8-57.as13285.net (78.144.8.57)  33.513 ms Host-78-144-12-213.as13285.net (78.144.12.213)  35.825 ms Host-78-144-10-37.as13285.net (78.144.10.37)  35.374 ms
 6  72.14.214.222 (72.14.214.222)  38.005 ms 72.14.242.127 (72.14.242.127)  35.820 ms 72.14.214.222 (72.14.214.222)  34.968 ms
 7  216.239.54.251 (216.239.54.251)  37.260 ms 64.233.174.83 (64.233.174.83)  22.876 ms 216.239.54.251 (216.239.54.251)  25.085 ms
 8  108.170.232.105 (108.170.232.105)  25.606 ms 108.170.232.103 (108.170.232.103)  27.050 ms  28.886 ms
 9  lhr25s11-in-f46.1e100.net (216.58.210.46)  29.601 ms  30.552 ms  31.896 ms
$ mtr --report google.com
Start: Wed Oct 26 11:07:33 2016
Host: localhost.localdomain       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway                    0.0%    10    1.2   1.6   1.1   2.7   0.5
  2.|-- Host-92-31-0-1.as13285.ne  0.0%    10   16.8  15.3  14.0  18.3   1.2
  3.|-- xe-11-2-0-bragg001.bre.as  0.0%    10   19.2  16.5  14.9  19.2   1.1
  4.|-- Host-78-151-225-30.static  0.0%    10   16.3  16.2  15.7  16.6   0.0
  5.|-- Host-78-144-12-147.as1328  0.0%    10   23.1  23.1  22.3  25.2   0.7
  6.|-- 72.14.242.127              0.0%    10   23.3  23.9  23.0  26.1   1.0
  7.|-- 216.239.54.251             0.0%    10   22.5  22.8  21.9  25.3   0.8
  8.|-- 108.170.232.105            0.0%    10   22.1  22.5  22.0  23.2   0.0
  9.|-- lhr25s11-in-f46.1e100.net  0.0%    10   23.3  23.4  22.7  24.3   0.0
unixtraceroute
2
sourcejedi

実際、最新のLinuxのtracerouteには、mtrの動作に一致するオプションがあります（その逆も同様です）。これはデフォルトの問題であることがわかります。

tracerouteがオリジナルでした。元のメソッドの詳細は documentation から推測できますが、それを詳しく説明する必要はないと考えられていました。 Linux tracerouteは複数のオプションを追加したため、違いについて説明します。

default

トレースルーティングの伝統的な古代の方法。デフォルトで使用されます。

プローブパケットは、いわゆる「ありそうもない」宛先ポートを持つudpデータグラムです。最初のプローブの「ありそうもない」ポートは33434であり、次に、次のプローブごとに1ずつインクリメントされます。

icmp

プローブにicmpエコーパケットを使用する、今のところ最も一般的な方法。宛先ホストにping（8）できる場合は、icmptraceroutingも適用できます。

mtrのデフォルトはicmpのようです。これは、「今のところ最も一般的な方法」です。

結論

マルチパスルーティングは、同じパス上の同じ接続からのパケットを保持することが期待されています。これにより、非常に望ましくない可能性のある異常な配信が回避されます。これは、送信元と宛先のアドレスとポートを調べることによって行われます。 （プロトコルとともに。これらの値は「5タプル」と呼ばれます）。

tracerouteのデフォルトでは、各プローブのUDPポートが変更されるため、パスが変更されます。

mtrのデフォルトはICMPエコーを使用しますが、これにはポート番号がないため、そのプローブはすべて同じパスをたどります。

UDPまたはTCP traceroute in mtrをリクエストすると、異なるパスが表示されます。tracerouteとは他の違いがあるかもしれませんが、この点で発生します。同様に動作します。

サイドトラック：なぜicmpが使用されなかったのですか？

そのため、Linux tracerouteは、デフォルトモードの選択を含め、意図的にオリジナルに忠実であり続けます。しかし、最初の選択の理由は完全には明らかではありません。

man tracepathを読んだことを思い出しました：

商用[IPv4]ルーターは、icmpエラーメッセージで十分な情報を返しません。おそらく、更新されると変更されます。今のところ、[tracepath]はVan Jacobsonのトリックを使用して、UDPポートの範囲をスイープしてトレース履歴を維持します。

ただし、重要なのは、tracepathが新しい機能を使用して、root権限を必要としないようにすることです。参照されている問題は、ICMPエラー応答に[〜＃〜] udp [〜＃〜]パケットのペイロードが含まれないことです。 ICMPエコーパケットのペイロードが含まれます（ただし、このようなプローブを生成するにはルートが必要です）。

Tracerouteは、ICMP TTL Exceededメッセージを個々のプローブに確実に一致させるために、送信される各プローブのUDP宛先ポート番号を変更（インクリメント）します。UDPポートはIPヘッダーの直後に発生するため、 ICMP標準では元のパケットのIPヘッダーに続く最初の8オクテットのみが義務付けられている場合でも、ICMPの「元のパケット」部分に含まれることを信頼できますTTL Exceeded messages ICMPメッセージに含まれます（ただし、さらに送信することは許可されています）。

ICMP ECHO要求を使用する場合、シーケンス番号フィールドを使用してプローブを明確にすることができます。このフィールドも、たまたまその8オクテット境界の直前にあります。

[〜＃〜] pert [〜＃〜] 提案を続けます

これは、RFC 792「インターネット制御メッセージプロトコル」の導入で指定されているように、当時、一部のゲートウェイ（ルーターが呼び出されたとき）がICMPメッセージに応答してICMP（TTL超過）メッセージの送信を拒否したためと考えられます。 。したがって、UDPバリアントはより堅牢でした。

ソースコードコメント UDPポートの使用についても説明しますが、UDP overICMPエコーの使用については説明しません。厳密に読むと、もう1つの可能性が示唆されます

icmpはicmpに送信されないため

コンテキストでは、応答の無限サイクルを回避するために、icmpresponseに応答してicmpエラーが送信されることはありません。実装がこれを応答だけでなくすべてのicmpパケットに適用することは確かにもっともらしいです。コメントには、tracerouteの結果を解釈するためにユーザーが留意しなければならない、さまざまな実装のバグについても言及されています。

しかし、ヴァン・ジェイコブソンが自分で要点を混同した可能性もあります。これが必ずしもicmpエコー要求に当てはまらないことを見逃して、icmpパケットに対してicmpエラーが返されないと単純に仮定するかもしれません。

これをコーディング例として使用しないでください。私はルーティングの問題を見つけようとしていましたが、このコードは48時間スリープせずに飛び出しました。私はそれがこれまでにコンパイルされたことに驚いていました。

2
sourcejedi