Высокий процент потерянных пакетов - TCP, ICMP - mtr - Пожаловаться на ISP?

проблема

У меня высокая потеря пакетов, согласно mtr, при отправке пакетов через интернет. Должен ли я пожаловаться своему провайдеру?

История

Я читаю OReilly Linux Networking Cookbook и глава Using traceroute, tcptraceroute, and mtr to Pinpoint Network Problems привлек мое внимание Пинг хоста, такого как Google, через Интернет от моего интернет-провайдера дает мне задержки записи 1200 мс и выше (не только с сегодняшнего дня; с давних времен), поэтому я подумал, что не стану хуже анализировать пути пакетов с 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 тестов, 1 тест каждые 5 минут; это отчет, который представляет надежное "среднее")

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. Что я должен сказать своему провайдеру? Как описать проблему?
  2. Какие исследования я могу сделать в дополнение к поиску неисправностей? * 1
  3. Какие-либо предложения?

* 1 Парни из техподдержки не всегда понимают, или я не могу выразить свою проблему достаточно ясно (иногда они просто идиоты, без сомнения)

Источник

4 ответа

Решение

Многие маршрутизаторы обычно запрограммированы на предоставление более низкого приоритета ICMP-пакетам, чтобы они не "теряли" вычислительную мощность по сравнению с "реальным" трафиком. То, что вы видите прыжок с большими потерями, не означает, что он замедляет "реальный" трафик; это может быть только выбрасывание ICMP. Это не обязательно хорошо, потому что это может означать, что маршрутизатор слишком занят, но это не гарантировано.

Маршрутизатор также может быть запрограммирован на ограничение количества ответов, которые он отправляет на пакеты ICMP, чтобы снизить вероятность атак DoS.

Источник

Может быть, ошибка внутри вашей сети.

Какой ваш интернет-маршрутизатор / шлюз?

Скорее всего, что

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

находятся в вашей собственной сети.

Источник

Что за соединение и подписная полоса пропускания? DSL, выделенная линия, Frame Relay, кабель? 768 вниз /128 вверх... и т. Д.

Вы можете получить более реалистичную информацию, используя WireShark, и захватывать / фильтровать пакеты между двумя хостами в течение периода времени (30 минут). Затем используйте Статистика> График потока TCP> График времени прохождения сигнала. Время кругового обхода (RTT) - это фактическая задержка на уровне TCP.

Источник

Учитывая, что у вас нулевой убыток в прыжке 15, вы знаете, что вы можете получить трафик полностью без потерь. Все числа потерь на переходах 1-15 являются "локальными", то есть маршрутизаторы не ответили на ICMP, но перенаправили ваш трафик.

Наибольшая потеря это на последнем прыжке, номер 20, поэтому лучше всего предположить, что проблема в заторе на другом конце. Сообщение о проблеме вашему интернет-провайдеру не принесет пользы, но, возможно, может помочь жалоба в службу, на которой он находится на другом конце.

Редактировать: я знаю, что это старый вопрос, но я думаю, что он заслуживает пояснения о том, как интерпретировать числа потерь>0 с последующими прыжками без потерь.

Источник
Другие вопросы по тегам