@dchostsupport
Чтобы определить, через какие маршрутизаторы прошёл пакет, следуя от вас к заданному 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 в этот момент, которое, как мы предполагаем, будет продолжаться до конца пути.
Это полезно, потому что если бы не было очевидно, что узел 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
