2

Я знаю, что сети используют несколько путей; они появляются в traceroute, но не в mtr. Мтр как-то придерживается первого пути? Что это за донг?

$ traceroute google.com
traceroute to google.com (216.58.210.46), 30 hops max, 60 byte packets
 1  gateway (172.16.9.1)  1.303 ms  1.332 ms  1.421 ms
 2  host-92-31-0-1.as13285.net (92.31.0.1)  14.965 ms  15.810 ms  16.978 ms
 3  xe-11-2-0-bragg001.bre.as13285.net (78.151.225.39)  19.456 ms  20.785 ms  23.052 ms
 4  host-78-151-225-14.static.as13285.net (78.151.225.14)  24.255 ms host-78-151-229-20.as13285.net (78.151.229.20)  25.979 ms host-78-151-225-18.static.as13285.net (78.151.225.18)  27.059 ms
 5  host-78-144-8-57.as13285.net (78.144.8.57)  33.513 ms host-78-144-12-213.as13285.net (78.144.12.213)  35.825 ms host-78-144-10-37.as13285.net (78.144.10.37)  35.374 ms
 6  72.14.214.222 (72.14.214.222)  38.005 ms 72.14.242.127 (72.14.242.127)  35.820 ms 72.14.214.222 (72.14.214.222)  34.968 ms
 7  216.239.54.251 (216.239.54.251)  37.260 ms 64.233.174.83 (64.233.174.83)  22.876 ms 216.239.54.251 (216.239.54.251)  25.085 ms
 8  108.170.232.105 (108.170.232.105)  25.606 ms 108.170.232.103 (108.170.232.103)  27.050 ms  28.886 ms
 9  lhr25s11-in-f46.1e100.net (216.58.210.46)  29.601 ms  30.552 ms  31.896 ms
$ mtr --report google.com
Start: Wed Oct 26 11:07:33 2016
HOST: localhost.localdomain       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway                    0.0%    10    1.2   1.6   1.1   2.7   0.5
  2.|-- host-92-31-0-1.as13285.ne  0.0%    10   16.8  15.3  14.0  18.3   1.2
  3.|-- xe-11-2-0-bragg001.bre.as  0.0%    10   19.2  16.5  14.9  19.2   1.1
  4.|-- host-78-151-225-30.static  0.0%    10   16.3  16.2  15.7  16.6   0.0
  5.|-- host-78-144-12-147.as1328  0.0%    10   23.1  23.1  22.3  25.2   0.7
  6.|-- 72.14.242.127              0.0%    10   23.3  23.9  23.0  26.1   1.0
  7.|-- 216.239.54.251             0.0%    10   22.5  22.8  21.9  25.3   0.8
  8.|-- 108.170.232.105            0.0%    10   22.1  22.5  22.0  23.2   0.0
  9.|-- lhr25s11-in-f46.1e100.net  0.0%    10   23.3  23.4  22.7  24.3   0.0

1 ответ1

2

На самом деле traceroute в современном Linux имеет опции, которые соответствуют поведению mtr (и наоборот). Мы видим, что это вопрос только по умолчанию.

traceroute был оригиналом. Детали оригинального метода могут быть выведены из документации, но это не было сочтено необходимым разъяснить его. Так как в трассировке Linux добавлено несколько опций, различия описаны.

дефолт

Традиционный, древний метод трассировки. Используется по умолчанию.

Пробные пакеты - это дейтаграммы udp с так называемыми "маловероятными" портами назначения. "Невероятный" порт первого зонда - 33434, затем для каждого следующего зонда он увеличивается на единицу.

ICMP

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

По умолчанию mtr выглядит как icmp, "самый обычный метод на данный момент".

Заключение

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

По умолчанию traceroute меняет порт UDP для каждого зонда, поэтому они меняют пути.

По умолчанию mtr использует эхо ICMP, у которого нет номера порта, и поэтому все его зонды будут следовать по одному и тому же пути.

Если вы запрашиваете трассировку UDP или TCP в mtr то отображаются разные пути. Могут быть другие различия по сравнению с traceroute , но в этом отношении он ведет себя аналогично.


Sidetrack: почему не использовался icmp?

Таким образом, traceroute Linux намеренно остается верным оригиналу, включая выбор режима по умолчанию. Но причина первоначального выбора не совсем понятна.

Я вспомнил, как читал man tracepath:

коммерческие маршрутизаторы [IPv4] не возвращают достаточно информации в сообщениях об ошибках icmp. Возможно, это изменится, когда они будут обновлены. На данный момент [tracepath] использует трюк Ван Якобсона, охватывающий диапазон портов UDP для поддержания истории трассировки.

однако суть в том, что tracepath использует более новые средства, чтобы избежать требования привилегий root. Упомянутая проблема заключается в том, что ответы об ошибках ICMP не будут включать в себя какую-либо полезную нагрузку пакета UDP . Полезная нагрузка эхо-пакета ICMP будет включена (но для генерации таких проб требуется root).

Traceroute изменяет (увеличивает) номер порта назначения UDP для каждого отправленного зонда, чтобы надежно сопоставлять сообщения ICMP TTL Exceeded с отдельными зондами. Поскольку порты UDP появляются сразу после заголовка IP, на них можно положиться, чтобы включить их в часть "исходного пакета" сообщений ICMP TTL Exceeded, хотя стандарты ICMP только предписывают, чтобы первые восемь октетов следовали за заголовком IP исходный пакет должен быть включен в сообщения ICMP (хотя разрешено отправлять больше).

Когда используются запросы ICMP ECHO, можно устранить неоднозначность зондов, используя поле порядкового номера, которое также находится непосредственно перед этой 8-октетной границей.

PERT продолжает предлагать

Считается, что это происходит потому, что в то время некоторые шлюзы (как тогда назывались маршрутизаторы) отказывались отправлять сообщения ICMP (превышено TTL) в ответ на сообщения ICMP, как указано во введении RFC 792, "Протокол управляющих сообщений Интернета" , Поэтому вариант UDP был более надежным.

Комментарии исходного кода также объясняют использование порта UDP, но не использование UDP поверх ICMP-эхо. Строгое чтение предполагает еще одну возможность

поскольку ICMP не отправляются для ICMP

В контексте дело в том, что ошибки icmp никогда не отправляются в ответ на ответ icmp, чтобы избежать бесконечного цикла ответов. Конечно, вполне вероятно, что реализации будут применять это ко всем пакетам icmp, а не только к ответам. В комментариях также упоминаются различные ошибки реализации, которые пользователи должны были учитывать, чтобы интерпретировать результат traceroute.

Однако также возможно, что Ван Якобсон сам с этим не согласен. Можно просто предположить, что ошибки icmp не будут возвращены ни для одного пакета icmp, упуская из виду, что это не обязательно относится к эхо-запросам icmp.

Не используйте это как пример кодирования. Я пытался найти проблему с маршрутизацией, и этот код выскочил через 48 часов без сна. Я был поражен тем, что он когда-либо компилировался, а тем более бегал.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .