30 Jul 2021 
Отдел Поддержки » Информационная база » PingPlotter как альтернатива tracert traceroute
 PingPlotter как альтернатива tracert traceroute
Решение

PingPlotter



Вступление

Pingplotter- это программа Windows, похожая на команду traceroute, которая показывает путь между клиентом и сервером, но делает это гораздо более информативно. В этой статье содержится информация об использовании этого инструмента, а также о некоторых типичных ошибках. Статья основана на аналогичной статье на портале Hetzner


Скачать

Бесплатную версию можно скачать с официального сайта .


Диагностика сети с помощью пингплоттера


На этом рисунке показан почти идеальный путь от клиента к серверу. Во втором столбце перечислены потери пакетов, то есть тестовые пакеты, которые были потеряны. Поскольку в этом примере не было потери пакетов, этот столбец пуст.

В столбцах IP и DNSName можно проследить путь, по которому проходят тестовые пакеты. Путь начинается с мюнхенского провайдера M-Net, на шагах 6 и 7 (на пиринговом узле INXS), переданных Noris, а затем, наконец, на шаге 9 (на пиринговом узле NIX), переданном сети Hetzner.

Столбцы Avg и Cur показывают время, необходимое пакету (в мс), чтобы добраться до перехода: Avg - среднее время, Cur - значение последнего тестового пакета.

В конце время передачи пакетов отображается графически. «Выбросы» можно быстро определить по красной линии. Однако вы можете сделать лишь ограниченные выводы из положения линии: черные линии показывают разницу между самым быстрым и самым медленным ответом для конкретного перехода. Однако, если прыжок реагирует особенно медленно, красная линия перемещается влево (поскольку справа требуется больше места).


mtr

Если у вас нет Pingplotter, вы можете получить те же базовые функции с программой mtr( WinMTR для Windows).  Сдесь можно взять ссылки для скачивания на WinMTR и другие полезные  программы https://help.gudzon.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=183


Типичные ошибки


Соединение «лагает»!

Время пинга к сайту увеличивается, терминальные сеансы отваливаются, админка сайта тормозит или виснет. Сервер не всегда является виновником, и использование ping в качестве диагностического инструмента здесь не очень помогает:


Pingplotter предлагает гораздо лучшую информацию:



Сразу видно, что ошибка (в этой проверке) находится в сети M-Netz. Начиная с шага 4, наблюдаются значительные задержки, пакеты с шага 5 частично отбрасываются (что, в свою очередь, может быть причиной ошибки на шаге 4), а шаг 6 приводит к чрезмерным задержкам. Подобные сценарии сбоев могут быть вызваны серьезными проблемами, например, вызванными DDoS-атаками.


Потеря пакетов


В этом примере дело обстоит иначе: несмотря на то, что имеется много отброшенных пакетов, начинающихся на переходе 10, время проверки связи 37 мс находится в нормальном диапазоне. Это могло быть вызвано неисправным маршрутизатором или неисправным кабелем.


Все идет медленно

В частности, при подключении по DSL часто появляется следующий экран с ошибкой:


Этот traceroute на самом деле не показывает проблему. Пингплоттер снова более полезен:


Высокая нагрузка уже на втором переходе указывает на перегрузку конечного интернет-соединения, которая может быть вызвана, например, отправкой больших объемов данных по электронной почте, засорением восходящего ADSL-соединения. Инструменты обмена файлами, которые в фоновом режиме поглощают трафик и о которых давно забыли, также могут быть проблемой. Четкую картину проблемы можно найти, выполнив трассировку в обратном направлении:


Все выглядит как норма (зеленый) до тех пор, пока маршрутизатор клиента не показывает просадку. Возможными проблемами могут быть нарушение подключения к Интернету или перегрузка маршрутизатора.


Потери пакетов, которые только выглядят как проблемы


На самом деле это не проблема / ошибка, поскольку отсутствие ответа на тестовые пакеты является нормальным явлением для маршрутизаторов. В зависимости от конфигурации маршрутизатора он будет маршрутизировать пакеты, но отвечать на тестовые пакеты только при наличии достаточной свободной вычислительной мощности. Пока следующие переходы не показали потерю пакетов, у Вас нет причин для беспокойства.


Асимметричная маршрутизация

Диагностика неисправности относительно проста, если круговой обход между клиентом и сервером следует по одному и тому же пути. Однако часто пакеты будут иметь разные  маршруты до серверов GudzonHost и обратно (это может быть вызвано разными подходами у провайдера клиента и  местоположения сервера (в нашем примере серверов Hetzner)).


Пример ошибки

В следующем примере сеть GudzonHost / Hetzner кажется причиной задержек. Начиная с первого маршрутизатора Hetzner, время запросов значительно увеличивается, и пакеты отбрасываются:

Client ---> Server

1  67 ms  65 ms  66 ms  62.26.xx.xx

2  63 ms  63 ms  65 ms  62.26.251.97

3  80 ms  74 ms  76 ms  so-6-0-0.core3.f.tiscali.de (62.27.95.2)

4  74 ms  75 ms  73 ms  so-3-0-0.fra30.ip.tiscali.net (213.200.64.25)

5  73 ms  74 ms  75 ms  ffm-s2-rou-1071.DE.eurorings.net (80.81.192.22)

6  75 ms  74 ms  75 ms  ffm-s1-rou-1001.DE.eurorings.net (134.222.227.65)

7  78 ms  79 ms  78 ms  nbg-s1-rou-1071.DE.eurorings.net (134.222.227.30)

8  84 ms  78 ms  79 ms  gi-0-1-286-nbg5.noris.net (134.222.107.26)

9  392 ms  393 ms  *  ne.gi-2-1.RS8000.RZ2.hetzner.de (213.133.96.65)

10  393 ms  *  392 ms  et-2-16.RS3000.RZ2.hetzner.de (213.133.96.38)

11  393 ms  392 ms  *  (...)


Только с traceroute в противоположном направлении был обнаружен фактический источник ошибки:


Server ---> Client

1  213.133.xx.xx (213.133.xx.xx)  0.233 ms  0.205 ms  0.281 ms

2  et-1-11.RS8000.RZ2.hetzner.de (213.133.96.37)  0.653 ms  0.660 ms  0.650 ms

3  nefkom-gw.hetzner.de (213.133.96.66)  1.119 ms  0.423 ms  0.415 ms

4  GW-SF-BBR-06-S2-3.nefkom.de (212.114.147.23)  0.635 ms  0.807 ms  0.457 ms

5  hsa2.mun1.pos6-0.eu.level3.net (212.162.44.25)  6.811 ms  6.347 ms  6.143 ms

6  ae0-19.mp1.Munich1.Level3.net (195.122.176.193)  315.587 ms  314.949 ms  315.164 ms

7  so-0-0-0.mp1.Frankfurt1.Level3.net (212.187.128.90)  301.324 ms  300.789 ms  300.742 ms

8  gige1-2.core1.Frankfurt1.Level3.net (195.122.136.101)  301.673 ms  300.853 ms  301.087 ms

9  de-cix.fra30.ip.tiscali.net (80.81.192.30)  -  317.844 ms  317.634 ms

10  so-4-0-0.core3f.tiscali.de (213.200.64.26)  318.453 ms  -  318.021 ms

11  so-1-0-0.core1.hh.tiscali.de (62.27.95.38)  307.780 ms  307.230 ms  307.252 ms

12  ge-2-0-0.7.core0.hh.tiscali.de (62.27.93.83)  307.431 ms  307.298 ms  307.084 ms

13  62.26.251.101 (62.26.251.101)  -  307.753 ms  308.933 ms

14  (...)  390.856 ms  399.355 ms  -

В этом случае произошла ошибка между двумя маршрутизаторами Level3 в Мюнхене. Проблема выглядит похожей на проблемы в Hetzner, поскольку пакеты до  8 шага (noris.net) были потеряны. Однако тестовые пакеты в сеть Hetzner и обратно пошли другим маршрутом, что показывают причину задержки в Мюнхене.



Подробности статьи
Номер статьи: 209
Создан: 11 Jun 2021 05:28 PM

 Ответ помог  Ответ не помог

 Назад
 Login [Забытый пароль] 
Email:
Password:
Remember Me:
 
 Поиск
 Настройки статьи
Home | Зарегистрироваться | Информационная база | Новости
Язык:

Help Desk Software By Kayako eSupport v3.50.05
Positive SSL