Как определить с помощью утилиты pathping в какой точке сети проблема?

Здравстуйте. Воспользовался утилитой pathping, но не смог понять где именно проблема - в первом узле, во втором узле или пролегает между ними.
Поиски в интернете не увенчались успехом - везде бездумно копируют и вставляют один и тот же пример, который всё же не объясняет, но запутывает понимание вывода этой утилиты.

6823f638b91749e8818cff58b4da7c6c.png

Прошу помочь мне понять:
1. Почему в таблице 2 столбца "Утер./Отпр.", а выводов 3;
2. Что означают столбцы "Исходный узел", "Маршрутный узел", дабы с их помощью можно было понять в какой из 3-ёх возможных точек находится проблема.

Пожалуйста, объясните мне так, словно я юный шкет, который консоль видит первый раз )

Спасибо за ответы.

добавил: ade9ef5665ae4aebb236a557e509907a.png
  • Вопрос задан
  • 4528 просмотров
Решения вопроса 1
IlyaEvseev
@IlyaEvseev
Opensource geek
pathping не очень нагляден, лучше WinMTR.
Инструкция по использованию: www.unetcom.ru/abonents/WinMTR
Ищите, с какой строки резко подпрыгнет время ответа и\или процент потерь станет ненулевым.
Точную причину он не покажет, но позволит определить, в чьей зоне ответственности причина находится.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@throughtheether
human after all
Как определить с помощью утилиты pathping в какой точке сети проблема?
Если вы не понимаете, что именно вы ищете при помощи pathping, то никак.

но не смог понять где именно проблема
Расскажите для начала, какую именно проблему вы наблюдаете? Медленно качаются файлы? Высокий пинг до какого-то хоста?

везде бездумно копируют и вставляют один и тот же пример,
Потому что они не знают страшной тайны - вывод pathping, mtr и прочих утилит имеет отношение к диагностируемой проблеме лишь в некоторых, далеко не во всех, случаях.

1. Почему в таблице 2 столбца "Утер./Отпр.", а выводов 3;
Третий вывод (справа от него стоит символ |) показывает на предполагаемый процент "потерь" на линке/хопе между соответствующими хостами (37% между 9 и 10 хопами в вашем случае).

UPD:

1. Ищу конкретно к кому обращаться на тему дурно работающего оборудования, так как порядком надоели проблемы с интернетом.
"Дурно работающее оборудование", "проблемы с интернетом" - это какие-то расплывчатые формулировки. Есть интернет. Есть в нем некие сервисы. Вы, используя различные (это важно) протоколы передачи данных, получаете к этим сервисам доступ. Есть различные количественные и качественные характеристики качества предоставления доступа/сервиса. Например, вчера сайт загружался за 1 секунду, а сегодня - за 3. Или вчера файл качался со скоростью 2 МБ/с, сегодня - 0.5. Или телефония вчера работала приемлемо, а сегодня голос стал металлическим и звонки стали сбрасываться.

2. Проблема - потеря данных. А это нестабильность связи, проблемы с ошибками при просмотре онлайн видео и прочие мморпг например.
В случае использования протокола TCP (например, просмотр видео на Youtube) потери пакетов могут приводить к уменьшению эффективной скорости передачи данных. Различные ошибки ("невозможно открыть файл, повторите еще раз"), на мой взгляд, чаще связаны с различными проблемами CDN (сети распределения контента, грубо говоря, сети кэширующих серверов).

3й пункт не совсем я понял. Для диагностирования проблемы на конкретном участке утилита вполне пригодна и справляется лучше чем traceroute, я не ошибаюсь?
Не думаю, что уместно сравнивать pathping и traceroute. На моей машине, например (windows 7), pathping 8.8.8.8 не отображает хопы, входящие в AS Google, a tracert отображает. Больше всего для диагностики проблем с доступом к некому сервису, на мой взгляд, полезно посылать сообщения того же протокола (http head, tcp syn в случае с web, tcp syn в случае tcp, udp-сообщения в случае udp) и анализировать количественные (задержка, отношение количества ответов к количеству запросов) и качественные (наличие ответов как таковых) характеристики взаимодействия. Например, в случае доступа к web-странице вывод ping может быть малорелевантен.


4. Тогда я не понимаю, почему и между линком и на исходном узле присутствуют потери. Означает ли это, что проблемы на исходном узле на самом деле вызваны проблемой коммутации меж узлов?

я не знаю что такое конкретно исходный узел, что такое конкретно маршрутный узел
Если я правильно понял, в колонке "исходный узел" (не самый лучший перевод оригинального названия "source to here") приведены показатели потерь при отправлении icmp-запросов непосредственно на данный хост. В этом случае трафик, как правило, обрабатывается отдельным процессором (входящим в control plane). С целью защиты control plane от DoS-атак трафик до него ограничивается (control plane protection policy в оборудовании Cisco, встроенный полисер в оборудовании Juniper). В колонке "маршрутный узел" приведены (оценочные) показатели потерь, вносимых непосредственно линком между текущим хопом и следующим. Подробнее здесь.


Кроме того, на добавленном новом скриншоте видно, что:
До узла kzn наблюдается потеря, а затем потери наблюдаются преимущественно в колонках "Исходный узел", что как я понимаю, относится к проблеме конкретно этих узлов, что в случае яндекса я верить отказываюсь, а значит ставлю под сомнение достоверность моего понимания этих данных.
Мое мнение таково - "потери" до узла kzn02.transtelecom.net обусловлены именно защитой control plane соответсвующего устройства (Juniper MX-серии, как предположение).
Комментировать оценки (предполагаю, основанного на статистике) алгоритма pathping, не зная его в деталях , не могу. Рекомендую диагностировать возможные проблемы более реалистичными средствами.
Ответ написан
opium
@opium
Просто люблю качественно работать
Это значи что проблема либо в отправке пакетов от 9 маршрутизатора, либо в соединении между девятым и десятым маршрутизатором, либо в приеме на 10 маршрутизаторе, надо на них просто зайти и посмотреть что не так, доступа у вас как полагаю никакого нет, так что вывод очевидный я написал выше.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы