Команда traceroute

Пример traceroute до публичного DNS-сервера компании Яндекс

Строки со звездочками (* * *) представляют узлы, от которых не было ответа, это может быть из-за настройки маршрутизатора на игнорирование запросов traceroute.
Если звездочки частичны, то это может быть или из-за потерь пакетов, или из-за настройки политик защиты маршрутизаторов (control-plane policy, CoPP), которые ограничивают количество ответов на запросы такого типа.
Время в миллисекундах в каждой строке — это время приема-передачи от источника до этого хопа.

traceroute -w 1 77.88.8.8
traceroute to 77.88.8.8 (77.88.8.8), 64 hops max, 52 byte packets
 1  router.local (172.16.1.1)  4.858 ms  4.628 ms  2.324 ms
 2  fw.local (172.16.0.36)  2.589 ms *  0.954 ms
 3  a481-cr02-be10.913.msk.mts-internet.net (195.34.50.193)  3.265 ms  1.312 ms  1.356 ms
 4  a481-cr01-ae1.236.msk.mts-internet.net (195.34.59.173)  2.542 ms  4.939 ms  1.017 ms
 5  a197-cr04-be13.236.msk.mts-internet.net (195.34.59.109)  2.752 ms  1.225 ms  1.562 ms
 6  a197-cr01-ae31.77.msk.mts-internet.net (212.188.56.13)  2.646 ms  1.505 ms  1.313 ms
 7  as13238.asbr.router (212.188.33.199)  4.046 ms  2.189 ms  2.065 ms
 8  * * vla-32z3-ae2.yndx.net (93.158.172.23)  9.212 ms
 9  * dns.yandex.ru (77.88.8.8)  6.295 ms *

Сетевой путь

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

Как работает traceroute?

Утилита traceroute отправляет пакеты на IP-адрес назначения со сроком жизни (TTL), установленным равным 1, первый роутер, на который придут пакеты, отправит обратно ошибку ("TTL expired").
При возврате ошибки инструмент traceroute записывает идентификатор первого маршрутизатора и время приема-передачи, увеличивает TTL (+1) и отправляет новые пакеты, повторяя этот процесс до тех пор, пока

  1) последний пакет не достигнет IP-адреса назначения
 или
  2) получит ответ о недоступности хоста назначения

Таким образом утилита позволяет определить путь и время в оба конца до каждого хопа.

Traceroute использует протокол ICMP (протокол управляющих сообщений в Интернете). ICMP — это протокол сетевого уровня, используемый для тестирования ошибок.
Он не имеет связанного транспортного протокола, работающего непосредственно по интернет-протоколу (IP). При превышении TTL пакета, отправленного инструментом traceroute, маршрутизатор отправляет обратно пакет ICMP Тип 11 (Ошибка превышения времени).

Исходящие пакеты могут использовать ICMP (по умолчанию в Unix-like операционных системах) или UDP (по умолчанию в Windows).
Выбор другого протокола для исходящих пакетов traceroute является одним из способов получения более полных результатов, если маршрутизаторы на сетевом пути настроены на фильтрацию пакетов определенного протокола.

My Traceroute (MTR)

MTR работает, обнаруживая сетевой путь аналогично traceroute, а затем регулярно отправляя пакеты для продолжения сбора информации, чтобы обеспечить обновленное представление о работоспособности и скорости сети.

Аналогично traceroute, MTR может использовать ICMP, UDP или TCP для исходящих пакетов, но полагается на ICMP для ответных пакетов (Тип 11: Время превышено).

Чтение результатов MTR

MTR № 1: Все отлично

laptop (172.16.1.34) -> www.mts.ru (212.188.8.51)                                          2023-08-30T13:39:01+0300
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                     Packets               Pings
Host                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
1. router.local                                                  0.0%    36    8.1   3.3   1.0  17.5   3.6
2. fw.local                                                    0.0%    35    0.9   0.9   0.6   2.7   0.3
3. a481-cr02-be10.913.msk.mts-internet.net                       0.0%    35    1.6   1.8   1.3   3.4   0.6
4. a481-cr01-ae1.236.msk.mts-internet.net                        0.0%    35    7.3   3.0   1.1   8.6   2.2
5. a197-cr04-be13.236.msk.mts-internet.net                       0.0%    35    1.8   1.6   1.3   3.3   0.3
6. a197-cr01-ae31.77.msk.mts-internet.net                       34.3%    35    2.6   3.5   2.3  10.9   1.8
7. mag9-cr02-be10.77.msk.mts-internet.net                        0.0%    35    2.3   2.6   2.2   4.5   0.4
8. mag9-cr03-be13.77.msk.mts-internet.net                        0.0%    35    2.2   3.1   2.0  28.1   4.4
9. a197-cr05-ae28.16.msk.mts-internet.net                        0.0%    35    2.0   2.8   1.9  26.9   4.2
10. mag9-cr03-be28.133.msk.mts-internet.net                       0.0%    35    2.9   6.0   2.7  77.9  13.3
11. mag9-cr02-be13.77.msk.mts-internet.net                       61.8%    35    2.9   3.1   2.7   5.0   0.6
12. m9-cr04-be8.77.msk.mts-internet.net                           0.0%    35    2.8   4.0   2.7  37.1   5.8
13. dor-cr01-ae5.97.msk.mts-internet.net                          0.0%    35    2.8   3.2   2.5   4.9   0.6
14. as13174.asbr.router                                           0.0%    35    3.3   3.6   3.1   6.3   0.7
15. 172.16.227.228                                                0.0%    35    3.4   3.6   3.2   7.4   0.8
16. 172.16.227.204                                                0.0%    35    3.5   3.8   3.5   5.7   0.4
17. 212.188.8.51                                                  0.0%    35    2.8   2.9   2.6   4.9   0.4

В данном примере показан сетевой путь между компьютером и сайтом mts.ru. Результат не указывает на наличие каких-либо проблем — для достижения сервера ему требуется 17 переходов.
При этом видно, что в трассе есть маршрутизаторы, которые с разной вероятностью отвечают на наши запросы (хопы 6 и 11), при этом последний хост, интересующий нас - не имеет потерь.
Это говорит о том, что на этих маршрутизаторах более жесткий механизм защиты, нежели на других маршрутизаторах. Это указывает на то, что сетевой путь фактически не является проблемным.

МТС, как и многие сетевые операторы во всём мире, устанавливает произвольные ограничения на количество пакетов, которые могут достигать уровня управления маршрутизатора. (Уровень управления — это центральный процессор маршрутизатора.) Чтобы предотвратить перегрузку плоскости управления слишком большим количеством таких пакетов, устанавливается ограничение числа запросов (или ограничение по ширине полосы для определенных типов трафика), поэтому мы наблюдаем все эти потери на промежуточных хопах, но не на последнем хопе: транзитный трафик до конечного узла не страдает.

MTR № 2: Все плохо

Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                     Packets               Pings
Host                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
1. router.local                                                  0.0%    12    2.1   2.9   1.4   6.2   1.4
2. fw.local                                                    8.3%    12    1.0   1.0   0.7   2.4   0.5
3. a481-cr02-be10.913.msk.mts-internet.net                       0.0%    12    1.5   1.8   1.3   3.3   0.6
4. trouble-host.mts.ru                                          50.0%    12    1.2   1.5   1.1   3.0   0.7

В данном примере показан сетевой путь между компьютером пользователя и web-сервером trouble-host.mts.ru. Результат показывает потерю пакетов на 2 и 4 переходах.
2й хоп в данной трассе - это фаерволл, на нём так же работает CoPP, ограничивающий его реакцию на icmp запросы, при этом видно, что на следюущем хопе потери не копятся, значит с транзитным трафиком всё впорядке.
Рассмотрим 4й хоп - чаще всего потери пакетов в MTR на последнем хопе говорят о наличии проблем либо по пути до этого хоста, либо на нём самом (например высокая утилизация процессора или сетевого интерфейса на конечном сервере, или проблемы в сегменте сети, который мы не видим).
Но в данном случае это сработало исскусственное огарничение ответов на запросы ICMP - 30 ответов в минуту.

На сервере работает web-приложение, проверим более детально есть ли проблемы с сервисом - сделаем проверку в режиме TCP по порту 443, на котором работает web-приложение:

MTR № 3: Оказывается не всё плохо

mtr -bez --tcp --port 443 trouble-host.mts.ru

Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                     Packets               Pings
Host                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
1. AS???    router.local (172.16.1.1)                          5.6%    18    2.8   2.2   1.3   3.0   0.5
2. AS???    fw.local (172.16.0.36)                           5.6%    18    1.2   1.2   1.1   1.3   0.1
3. AS8359   a481-cr02-be10.913.msk.mts-internet.net (195.34.50.193)  5.6%    18    2.1   1.9   1.6   2.1   0.2
4. AS8359   trouble-host.mts.ru                              0.0%    18    1.6   1.5   1.3   2.0   0.1

Получаем следующий интересный результат, видим в каждом хопе IP-адрес, номер автономной системы для публичных адресов, и не видим меток MPLS, т.к. в данной короткой трассе просто наш трафик не успевает дойти до MPLS сегмента.
Вывод говорит, что на транзитных маршрутизаторах есть ситуация, когда работа механизмов защиты уровня управления не отвечает на запросы на порт TCP/443 (скорее всего превышен лимит ответов TCP RST, сбрасывающий эти соединения), но конечный хост исправно отвечает на наши запросы.
Такую же ситуацию может показать оборудование защиты ресурсов от DDoS-атак, фаерволлы или балансировщики - вариантов может быть много.

В конечном счете, пользуйтесь утилитами и правильно оценивайте результаты их работы, ошибка в интерпретации результатов может увести вас в поиске проблем далеко и не туда.