web-dev-qa-db-ja.com

失われたパケットの割合が高い-TCP、ICMP-mtr-ISPに文句を言う？

問題

mtrによると、インターネット経由でパケットを送信すると、パケット損失が大きくなります。 ISPに文句を言うべきですか？

物語

私はOReilly Linux Networking Cookbookを読んでいて、Using traceroute, tcptraceroute, and mtr to Pinpoint Network Problemsの章が私の注意を引きました。インターネット経由でGoogleのようなホストにpingを実行する 私のISPから は1200ms以上の記録的な遅延をもたらします（今日からだけでなく、長い間）、 mtrでパケットの方法を分析するのは悪くないと思いました。

Mtr is a network diagnostic tool that combines ping and traceroute into one program.

抜粋と同時に、この質問スレッドの理由は次のとおりです。

これらのいずれかが常に同じルーターでハングアップする場合、またはmtrが同じルーターで常に5％を超えるパケット損失と長い通過時間を示す場合は、特定のルーターに問題があると言っても過言ではありません。制御するルーターの場合は、念のために修正してください。そうでない場合は、Digまたはwhoisを使用して、それが誰に属しているかを調べ、問題を適切に報告してください。

問題

mtr --report www.google.comの出力を自分で参照してください：（合計12回のテスト、5分ごとに1回のテスト、これは信頼できる「平均」を表すレポートです）

Host: km                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.0.1                   0.0%    10    1.2   3.7   1.2   6.3   1.8
  2. 10.150.144.145               10.0%    10   89.1  77.3  58.7  90.4  11.1
  3. 172.16.251.1                 50.0%    10   52.2  62.1  52.2  70.3   8.8
  4. 172.16.250.54                60.0%    10   74.9  87.5  74.9 100.4  12.1
  5. 172.16.250.251               40.0%    10   68.6  75.4  52.4 113.8  24.2
  6. 200.85.47.2                  10.0%    10  109.6 110.6  80.6 146.2  21.1
  7. 201.217.4.113                 0.0%    10  103.6  87.3  64.4 103.7  12.2
  8. 201.217.0.9                   0.0%    10  229.0 102.6  46.7 229.0  48.1
  9. 201.217.0.3                   0.0%    10   78.8  88.1  53.9 128.8  23.8
 10. So2-3-2-0-grtbueba2.red.tele  0.0%    10  134.1 129.2  71.3 176.6  29.2
 11. Xe4-1-3-0-grtmiabr7.red.tele  0.0%    10  257.3 255.1 221.0 291.6  21.1
 12. Xe2-0-2-0-grtmiana3.red.tele  0.0%    10  290.4 267.0 213.2 319.1  31.0
 13. Xe2-0-2-0-grtmiana3.red.tele  0.0%    10  300.0 250.8 217.3 312.7  34.6
 14. GOOGLE-xe-5-0-0-0-grtmiana3. 10.0%    10  249.8 256.9 206.7 324.0  34.6
 15. 209.85.254.252                0.0%    10  254.3 253.8 217.1 283.1  23.4
 16. 209.85.254.252               10.0%    10  301.2 280.6 252.1 319.7  21.6
 17. 72.14.236.200                10.0%    10  273.4 278.4 238.4 311.0  25.0
 18. 216.239.49.145               20.0%    10  291.0 276.3 240.4 293.5  19.1
 19. 72.14.232.25                 10.0%    10  297.9 286.3 242.4 337.1  30.0
 20. yo-in-f105.1e100.net         70.0%    10  300.7 304.7 280.3 333.0  26.6

ホスト3〜5で5％をはるかに超える非常に高いパケット損失が発生していることがすぐにわかります。 whoisデータベースクエリを実行すると、それらがネームサーバーであることがわかります（間違っている場合は修正してください）。

質問

  1. ISPに何を伝えるべきですか？問題の説明方法..？
  2. トラブルシューティングを容易にするために、どのような調査を行うことができますか？* 1
  3. 何か提案はありますか？

* 1テクニカルサポートの人たちはいつも理解しているとは限らないか、私の問題を十分に明確に表現することができません（時には彼らは間違いなくばかです）

networkinginternettcpgooglemtr
5
Kenny Meyer

多くのルーターは通常、ICMPパケットの優先度を低くするようにプログラムされているため、「実際の」トラフィックよりも処理能力を「浪費」することはありません。損失の大きいホップが表示されたからといって、それが「実際の」トラフィックの速度を低下させているわけではありません。 ICMPを破棄しているだけかもしれません。ルーターがビジー状態である可能性があるため、必ずしも良いとは限りませんが、保証はされていません。

ルーターは、DoS攻撃を軽減するために、ICMPパケットに送信する応答の数を制限するようにプログラムすることもできます。

11
Keith Stokes

エラーがネットワーク内にある可能性があります。

あなたのインターネットルーター/ゲートウェイはどれですか？

たぶんそれ

3. 172.16.251.1    50.0%    10   52.2  62.1  52.2  70.3   8.8
4. 172.16.250.54   60.0%    10   74.9  87.5  74.9 100.4  12.1
5. 172.16.250.251  40.0%    10   68.6  75.4  52.4 113.8  24.2

あなた自身のネットワークの中にあります。

1
cstamas

ホップ15で損失がゼロであることを考えると、損失なしでそこまでトラフィックを取得できることがわかります。ホップ1〜15のすべての損失数は「ローカル」です。つまり、ルーターはICMPに応答していませんが、トラフィックを転送しています。

ラストホップで最も損失が大きいのは20番なので、問題はもう一方の端の輻輳であると推測されます。 ISPへの問題報告は役に立たないでしょうが、おそらく相手側のサービスに対する苦情が役立つかもしれません。

編集：これは古い質問だと思いますが、0を超える損失数とそれに続く損失のないホップを解釈する方法について説明する価値があると思います。

0
Jakob Borg

どのような接続とサブスクライブされた帯域幅ですか？ DSL、専用線、フレームリレー、ケーブル？ 768ダウン/ 128アップ...など.

WireSharkを使用してより現実的な情報を取得し、一定期間（30分）2つのホスト間でパケットをキャプチャ/フィルタリングできます。次に、統計> TCPストリームグラフ>ラウンドトリップ時間グラフを使用します。ラウンドトリップ時間（RTT）は、tcpレイヤーでの実際の遅延です。

0
Greg Askew