Как правильно интерпретировать результаты traceroute или MTR

Когда пакет передаётся по сети, он проходит через несколько маршрутизаторов. Чтобы определить, через какие маршрутизаторы прошёл пакет, следуя от вас к заданному IP-адресу, можно использовать инструменты traceroute и My Traceroute (MTR)

Traceroute — это простой инструмент, тогда как MTR позволяет запускать и агрегировать результаты нескольких traceroute. Если вы просто хотите узнать маршрут пакета — вам подойдёт traceroute. Если же вам нужно диагностировать потерю пакетов — используйте MTR.

В этой статье мы рассмотрим трассировку на примере вывода MTR, поскольку данный инструмент более универсален.

Типы трассировки

Traceroute и MTR поддерживают разные типы трассировки. Два основных: 

  • протокол пользовательских датаграмм (UDP)  
  • и протокол межсетевых управляющих сообщений (ICMP).

Оба типа отправляют серию пакетов с постепенно увеличивающимся значением Time to Live (TTL). Идея заключается в том, что если отправить пакет с TTL=1 — он будет отклонён на первом маршрутизаторе в сети и вы получите сообщение об ошибке ICMP «Time-to-live exceeded». Затем отправляем пакет с TTL=2, и он отклоняется на втором маршрутизаторе, и так далее. Таким образом, мы используем исходный IP-адрес и тайминги сообщений о превышении времени TTL для построения нашего списка путей.

Некоторые маршрутизаторы не будут отправлять сообщения о превышении времени TTL для UDP, ICMP или обоих. По опыту автора, ICMP — более надёжный тип трассировки, поэтому лучше начать с него. Чтобы воспользоваться ICMP, вызовите команду traceroute с ключом traceroute -I. Для MTR ICMP обычно используется по умолчанию, поэтому ключ не требуется.

Поля MTR

Вывод команды MTR выглядит примерно так:

My traceroute  [v0.92]

home (62.3.100.24)                                  2022-03-17T18:20:20+0000

Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                       Packets               Pings

 Host                                Loss%   Snt   Last  Avg  Best  Wrst StDev

 1. 62-3-100-30.dsl.in-addr.zen.co.u  0.0%    5    0.6   0.6   0.5   0.6   0.0

 2. ???

 3. lag-8.p2.thn-lon.zen.net.uk       0.0%    5   12.3  12.3  12.2  12.5   0.1

 4. lag-2.br1.thn-lon.zen.net.uk      0.0%    5   12.3  12.3  12.0  12.5   0.2

 5. 72.14.223.28                      0.0%    5   12.9  12.8  12.4  12.9   0.2

 6. 209.85.249.149                    0.0%    5   13.4  13.7  13.3  14.2   0.4

 7. 142.251.54.27                     0.0%    5   12.0  11.8  11.4  12.0   0.2

 8. dns.google                        0.0%    4   12.1  11.8  11.6  12.1   0.2

 

Вы увидите:

  • Имя хоста или IP-адрес конкретного прыжка в сети (запустите mtr -n, если вы не хотите, чтобы он преобразовывал IP-адрес в имя хоста).
  • Процент пакетов, потерянных этим прыжком.
  • Количество пакетов, отправленных во время прыжка.
  • Время в пути туда и обратно (то есть сколько времени потребовалось, чтобы получить ответ).
  • Среднее, лучшее, худшее и стандартное отклонение времени с момента запуска MTR.

MTR прыжки

В приведенном выше выводе MTR вы видите восемь прыжков. Второй прыжок отображает хост как «???». Это потому, что он не отправил сообщение о превышении времени TTL в ответ.

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

Если все хосты находятся в конце, это может указывать на проблему (то есть на 100% потерю пакетов с этой точки). Либо может просто означать, что ни один из последних прыжков не отправляет сообщения с превышенным временем TTL. Трудно сказать.

DNS-имена MTR прыжков

DNS-имена, отображаемые MTR, могут быть очень информативными. Многие крупные провайдеры помещают информацию о своих маршрутизаторах в DNS-имя. В приведенном выше примере вы увидите lag-2.br1.thn-lon.zen.net.uk. Скорее всего, это интерфейс агрегации каналов 2 на маршрутизаторе br1 в центре обработки данных Telehouse North в Лондоне, Великобритания. Таким образом, мы начинаем понимать, какой физический путь по всему миру проходит пакет.

Посмотрите на приведенный ниже вывод MTR:

                             My traceroute  [v0.92]

home (62.3.100.24)                                   2022-03-17T18:32:05+0000

Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                       Packets               Pings

 Host                                Loss%   Snt  Last  Avg  Best  Wrst  StDev

 1. 62-3-100-30.dsl.in-addr.zen.co.u  0.0%   18   0.5   0.5   0.4   0.9   0.1

 2. ???

 3. lag-8.p2.thn-lon.zen.net.uk       0.0%   18  12.1  12.3  11.9  12.7   0.2

 4. lag-2.br1.thn-lon.zen.net.uk      0.0%   18  12.1  12.6  11.9  15.5   1.0

 5. ge-3-3-0.mpr1.lhr3.uk.above.net   0.0%   18  11.9  12.3  11.7  13.7   0.6

 6. ae10.cs3.lhr11.uk.zip.zayo.com   88.2%   18  83.5  83.7  83.5  83.9   0.3

 7. ae5.cs1.lga5.us.eth.zayo.com      0.0%   18  82.9  83.8  82.7  90.4   1.8

 8. ae8.mpr3.bos2.us.zip.zayo.com     0.0%   18  87.3  83.6  82.6  87.3   1.5

 9. ???

10. ???

11. http-lb-02.us.cloudcall.com       0.0%   17  88.8  90.0  88.3  92.1   1.2

Мы видим, что пакет проходит через:

  • Zen in London Telehouse North
  • Zayo / AboveNet в Лондоне (многие провайдеры любят использовать коды аэропортов для определения местоположения маршрутизатора. LHR - Лондон Хитроу.)
  • Zayo в Нью-Йорке
  • Zayo в Бостоне

Это также означает, что пункт назначения, вероятно, является клиентом Zayo, но мы не можем сказать наверняка, так как прыжки 9 и 10 пусты.

Потеря пакетов и время в пути

В приведенном выше примере вы видите, что у восьмого прыжка (ae10.cs3.lhr11.uk.zip.zayo.com ) показатель потери пакетов — 88,2%. Это плохо, правда? На самом деле, нет. Потеря пакетов и увеличение времени в пути (RTT) на одном прыжке ожидаемы, если этот прыжок ограничивает скорость, с которой он отправляет сообщения ICMP о превышении времени TTL.

Ключевая вещь, которую многие люди не понимают в MTR или traceroute, заключается в следующем: если потеря пакетов или увеличение RTT не наблюдаются при каждом прыжке между данным прыжком и концом пути — это не проблема.

Возьмем, к примеру, такой маршрут трассировки:

ХОСТ: localhost Loss% Snt Last Avg Best Wrst StDev

 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3

 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8

 3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7

 4. aix.pr1.atl.google.com 60,0% 10 6,7 6,8 6,7 6,9 0,1

 5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9

 6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2

 7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3

 8. gw-in-f147.1e100.net 40,0% 10 39,6 40,5 39,5 46,7 2,2

Мы видим, что на 3-м прыжке происходит 60% потери пакетов, и эта потеря сохраняется до конца пути и в итоге составляет 40%. Это означает, что прыжок 3, возможно (см. раздел ниже о прямом и обратном пути), приводит к потере пакетов, а общая потеря между вами и пунктом назначения составляет 40%. Остальные 20% можно игнорировать.

Чему мы можем научиться у RTT

RTT каждого прыжка — полезная метрика, потому что говорит нам, сколько времени потребовалось пакету, чтобы добраться до этого прыжка, по сравнению с предыдущим. Возьмём такой вывод MTR:

                                      My traceroute  [v0.92]

home (62.3.100.24)                                                2022-03-17T18:57:17+0000

Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                                         Packets               Pings

 Host                                                  Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. 62-3-100-30.dsl.in-addr.zen.co.uk                   0.0%     7    0.5   0.6   0.5   0.8   0.1

 2. ???

 3. lag-8.p1.thn-lon.zen.net.uk                         0.0%     7   12.2  15.8  12.2  25.2   6.2

 4. lag-1.br1.thn-lon.zen.net.uk                        0.0%     7   12.3  12.9  12.1  16.4   1.6

 5. ldn-b3-link.ip.twelve99.net                         0.0%     6   12.1  12.7  12.0  15.6   1.4

 6. ldn-bb4-link.ip.twelve99.net                        0.0%     6   12.2  12.3  11.9  12.9   0.4

 7. nyk-bb1-link.ip.twelve99.net                        0.0%     6   84.5  84.5  84.3  84.7   0.2

 8. nyk-b2-link.ip.twelve99.net                         0.0%     6   81.7  81.7  81.6  81.9   0.1

 9. choopa-svc071182-lag000971.ip.twelve99-cust.net     0.0%     6   88.5  86.9  81.3  95.9   6.5

10. ???

Мы видим, что RTT резко возрастает между прыжками 6 и 7. По DNS-именам мы видим, что 6-й узел находится в Лондоне, Великобритания, тогда как 7-й — в Нью-Йорке, США. Таким образом, можно ожидать значительного увеличения RTT в этот момент, которое, как мы предполагаем, будет продолжаться до конца пути.

Помните: если потеря пакетов или увеличение RTT не наблюдаются при каждом прыжке между данным прыжком и концом пути — это не проблема.

Это полезно, потому что если бы не было очевидно, что узел 6 находится в Великобритании, а 7 — в США, мы не смогли бы ясно увидеть, где пакет пересёк Атлантику.

Если мы знаем, что и источник, и пункт назначения находятся в Великобритании, и видим значительное увеличение RTT между данным прыжком и концом пути — значит, что-то не так. Возможно, это действительно долгий путь (например, в США и обратно) или конкретный прыжок, возможно, приводит к задержке.

Примечание о MPLS

Вы можете посмотреть на трассировку между Великобританией и Австралией и увидеть, что пакет покидает Великобританию на 5-м пряжке, а затем прибывает в Австралию на 6-м. На самом деле, это почти наверняка не происходит непосредственно между этими двумя точками. В середине — многопротокольная сеть переключения меток (MPLS), которая в некоторой степени скрывает путь. Это не имеет значения, как если бы вы были уверены, что узел Zayo создает проблемы — неважно, находится ли он в Лондоне или Лас-Вегасе, это все равно проблема Zayo.

Забавный совет: вы можете нажать e во время работы MTR, чтобы увидеть метки MPLS из некоторых прыжков:

                                      My traceroute  [v0.92]

home (62.3.100.24)                                                       2022-03-17T19:08:05+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                                         Packets               Pings

 Host                                                  Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. 62-3-100-30.dsl.in-addr.zen.co.uk                   0.0%    74    0.4   0.5   0.4   0.8   0.1
 2. ???
 3. lag-8.p2.thn-lon.zen.net.uk                         0.0%    74   12.6  13.7  12.0  32.0   3.4
    [MPLS: Lbl 24012 Exp 0 S 1 TTL 1]
 4. lag-2.br1.thn-lon.zen.net.uk                        0.0%    74   17.7  14.2  11.8  35.4   4.4
 5. bbr02.lon01.networklayer.com                        0.0%    74   12.1  13.5  11.7  30.0   3.2
 6. ae5.cbs01.tg01.lon01.networklayer.com              64.4%    74   12.8  15.1  12.6  21.3   2.9
    [MPLS: Lbl 205039 Exp 0 S 1 TTL 1]
 7. ae0.cbs01.xn01.fra01.networklayer.com              41.1%    74   26.7  25.3  23.4  43.4   3.4
    [MPLS: Lbl 126402 Exp 0 S 1 TTL 1]
 8. ae0.cbs02.ic01.mil02.networklayer.com               1.4%    74   32.5  35.7  32.5  61.2   5.4
    [MPLS: Lbl 809963 Exp 0 S 1 TTL 1]
 9. ae7.cbs01.ic01.mil02.networklayer.com              21.9%    73   34.9  35.4  32.6  65.7   5.4
    [MPLS: Lbl 288384 Exp 0 S 1 TTL 1]
10. 61.13.2da9.ip4.static.sl-reverse.com               30.1%    73  242.4 244.3 242.3 254.7   2.6
    [MPLS: Lbl 423005 Exp 0 S 1 TTL 1]
11. af.13.2da9.ip4.static.sl-reverse.com                0.0%    73  242.3 244.1 241.8 257.6   3.7
    [MPLS: Lbl 499542 Exp 0 S 1 TTL 1]
12. cb.12.6132.ip4.static.sl-reverse.com                0.0%    73  242.8 244.1 242.5 254.5   2.5
13. po2.fcr01.sr03.sng01.networklayer.com              30.1%    73  261.2 277.6 260.8 547.7  52.5
14. sip3.nexmo.com                                      0.0%    73  242.4 243.4 242.1 258.0   2.5

Понимание прямого и обратного пути

Путь, по которому пакет проходит между A и B, часто не совпадает с путем, по которому он проходит между B и A. Таким образом, если вы пингуете определенный IP-адрес, то ваш ping (echo request), скорее всего, будет идти по другому пути, нежели ответ (echo reply).

Это означает, что когда вы используете MTR или traceroute и видите потерю пакетов, начиная с конкретного прыжка — это не обязательно тот прыжок, который привёл к проблеме. Представьте себе путь, который выглядит следующим образом:

Вы (Zen ISP) -> Zayo (крупный транзитный провайдер) -> Amazon Web Services

В вашей трассировке вы видите 40%-ную потерю пакетов где-то на краю сети AWS. Вы не видите никаких потерь в Zen или Zayo ... Так что проблема должна быть в AWS, верно?

Нет. AWS может использовать другой путь, чтобы связаться с вами из своей сети. Может быть, это:

AWS -> NTT (другой крупный транзитный провайдер) -> You (Zen ISP).

Возможно, ваш пинг-пакет попал в AWS и это были, по сути, ответные пакеты, которые теряются где-то внутри NTT.

Единственный способ узнать наверняка — пройти трассировку с обоих концов (то есть трассировать от вас до пункта назначения и снова от пункта назначения до вашего IP-адреса). Это не всегда возможно, если целью является чужой веб-сайт.

На самом деле, в приведенном выше случае проблема все еще в AWS. У них есть контракт с NTT, NTT не работает, AWS должен поговорить с NTT. В некоторых других случаях, когда используется «settlement-free» (то есть бесплатный) пиринг, например, в точках обмена трафиком, это может быть политически сложно, поскольку ни у кого нет контракта или соглашения о поддержке, к которому можно было бы прибегнуть, когда что-то не работает.

 

Перевод статьи How to properly interpret a traceroute or MTR

Этот материал был полезен?

Скидка 25% новым клиентам!
Закажи сервер сегодня и получи скидку на первый месяц аренды!