Диагностика доступности сервера или сети

Диагностика сети с pingplotter

Pingplotter это программа под Windows, похожая на команду traceroute. Она показывает путь пакетов между клиентом и сервером удобным образом. Бесплатная 30-дневная пробная версия pingplotter доступна на сайте производителя

http://www.pingplotter.com

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

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

В колонках Avg и Cur показывается время (в миллисекундах), за которое пакет достигает узла. Avg это среднее время, Cur — время из последней проверки.

В последней колонке время передачи пакетов отображается графически. Большие изменения легко заметить по форме красной линии. В дополнение к этому также следует обратить внимание черную линию. Она показывает разницу между наилучшим и наихудшим временем ответа на конкретном узле. Если какой-то узел периодически отвечает медленно, то пересечение красной и чёрной линий будет смещаться влево.

mtr

Если у вас нет возможности воспользоваться Pingplotter, то схожую функциональность можно получить от программы mtr (WinMTR для Windows). Подробнее об использовании mtr написано здесь.

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

«Лагает»!

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

Pingplotter предоставляет гораздо больше информации:

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

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

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

Всё тормозит

Для DSL подключений часто можно увидеть такую картину:

Вывод traceroute не может дать достаточно полную информацию. Вот так выглядит вывод Pingplotter в такой же ситуации:

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

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

Потеря пакетов, которой нет

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

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

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

Следующая Flash-анимация на немецком языке иллюстрирует проблема:

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

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

Клиент ---> Сервер

Реальный источник проблемы обнаруживается только при обратной проверке:

Сервер ---> Клиент

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