Диагностика сети с 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 сильно возрастает время ответа и появляются потери:
Клиент ---> Сервер
| 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 | * | (...) |
Реальный источник проблемы обнаруживается только при обратной проверке:
Сервер ---> Клиент
| 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 (пакеты до восьмого узла (Noris) были удачно доставлены обратно). Однако пакеты к сети Hetzner и из неё шли разными путями, что не позволило достоверно определить проблему по одной трассировке.
