Содержание
Команда traceroute используется в Linux для отображения пути прохождения пакета информации от его источника к месту назначения. Одним из способов использования traceroute является обнаружение случаев потери данных по всей сети, что может указывать на то, что узел не работает.
Поскольку каждый переход в записи отражает новый сервер или маршрутизатор между исходным ПК и предполагаемой целью, просмотр результатов сканирования трассировки также позволяет выявлять медленные точки, которые могут отрицательно повлиять на сетевой трафик.
Синтаксис traceroute и другая информация, описанная ниже, применима только к машинам Linux. Traceroute по-разному используется в Windows.
Как работает Traceroute
Оценка конкретного маршрута, по которому следует сетевой трафик (или нахождение неверного шлюза, отбрасывающего ваши пакеты), представляет несколько проблем, связанных с устранением неполадок. Traceroute использует поле протокола времени жизни IP для запроса ответа ICMP TIME_EXCEEDED от каждого шлюза по пути к хосту назначения.
Единственный параметр, который необходимо указать при выполнении команды traceroute, — это имя хоста или IP-адрес места назначения.
Синтаксис трассировки и переключатели
Синтаксис трассировки в Ubuntu.
трассировка [ -dFInrvx ] [ -е first_ttl] [ -грамм Шлюз] [ -я я лицо ] [ -м max_ttl] [ -п порт] [ -Q nqueries] [ -s src_addr] [ -T tos] [ -вес время ожидания ] [ -Z pausemsecs] хост [packetlen]
Хотя вышеизложенное показывает, как команда traceroute должна быть записана для работы в командной строке, производительность или выходные данные команды можно изменить, указав один или несколько необязательных переключателей.
| переключатель | объяснение |
| -е | Установите начальное время жизни, используемое в первом исходящем тестовом пакете. |
| -F | Установите бит «не фрагментировать». |
| -d | Включить отладку на уровне сокетов. |
| -грамм | Укажите свободный исходный маршрутный шлюз (максимум 8). |
| -я | Укажите сетевой интерфейс для получения исходного IP-адреса для исходящих тестовых пакетов. Обычно это полезно только на многосетевом хосте. (См. -s флаг для другого способа сделать это.) |
| -я | Используйте ICMP ECHO вместо дейтаграмм UDP. |
| -м | Установите максимальное время жизни (максимальное количество прыжков), используемое в исходящих тестовых пакетах. По умолчанию используется 30 переходов (то же самое, что используется по умолчанию для соединений TCP). |
| -N | Распечатывать адреса прыжков численно, а не символически и численно (сохраняет поиск адреса к имени сервера имен для каждого шлюза, найденного в пути). |
| -п | Установите базовый номер порта UDP, используемый в пробниках (по умолчанию 33434). Traceroute надеется, что на базе портов UDP ничего не прослушивается base + nhops — 1 на хосте назначения (поэтому будет возвращено сообщение ICMP PORT_UNREACHABLE для завершения трассировки маршрута). Если что-то прослушивает порт в диапазоне по умолчанию, этот параметр можно использовать для выбора неиспользуемого диапазона портов. |
| -р | Обходите обычные таблицы маршрутизации и отправьте напрямую на хост в подключенной сети. Если хост не находится в сети с прямым подключением, возвращается ошибка. Эта опция может использоваться для проверки связи с локальным хостом через интерфейс, у которого нет маршрута через него (например, после того, как интерфейс был сброшен маршрутизируемым (8C)). |
| -s | Используйте следующий IP-адрес (который обычно задается как IP-адрес, а не имя хоста) в качестве адреса источника в исходящих тестовых пакетах. На многодомных хостах (с более чем одним IP-адресом) этот параметр можно использовать, чтобы заставить исходный адрес отличаться от IP-адреса интерфейса, на который отправляется тестовый пакет. Если IP-адрес не является одним из адресов интерфейса данного аппарата, возвращается ошибка и ничего не отправляется. (См. -я флаг для другого способа сделать это.) |
| -T | Установите для типа обслуживания в тестовых пакетах следующее значение (по умолчанию ноль). Значение должно быть десятичным целым числом в диапазоне от 0 до 255. Этот параметр можно использовать, чтобы увидеть, приводят ли разные типы обслуживания к разным путям. (Если вы не используете 4.4bsd, это может быть академическим, так как обычные сетевые сервисы, такие как telnet и ftp, не позволяют вам контролировать TOS.) Не все значения TOS являются законными или значимыми — см. Определения IP-спецификации. Полезные значения, вероятно, `-T 16 ‘(низкая задержка) и `-T 8 ‘(высокая пропускная способность). |
| -v | Подробный вывод. Полученные ICMP-пакеты, кроме TIME_EXCEEDED и UNREACHABLE, перечислены. |
| -вес | Установите время (в секундах) ожидания ответа на зонд (по умолчанию 5 секунд). |
| -Икс | Переключить контрольные суммы IP. Обычно это не позволяет traceroute вычислять контрольные суммы IP. В некоторых случаях операционная система может перезаписывать части исходящего пакета, но не пересчитывать контрольную сумму; таким образом, в некоторых случаях по умолчанию не вычисляются контрольные суммы и используется -Икс заставляет их рассчитывать. Обратите внимание, что контрольные суммы обычно требуются для последнего прыжка при использовании зондов ICMP ECHO (-я), поэтому они всегда рассчитываются при использовании ICMP. |
| -Z | Установите время (в миллисекундах) для паузы между датчиками (по умолчанию 0). Некоторые системы, такие как Solaris и маршрутизаторы от Cisco, ограничивают скорость передачи сообщений icmp. Хорошее значение для использования это 500 (например, 1/2 секунды). |
Интерпретация результатов
Traceroute обрисовывает путь, по которому IP-пакет следует к интернет-хосту, запуская тестовые пакеты UDP с небольшим TTL, а затем прослушивая ICMP-ответ «превышено время» от шлюза. Запустите тестирование с TTL, равным единице, и увеличивайте на единицу, пока не получите ICMP «порт недоступен» (что означает, что пакет прибыл в пункт назначения) или не достигните максимального значения попыток, которое по умолчанию составляет 30 прыжков и может быть изменено с помощью -м флаг.
Когда traceroute выполняется, он отправляет три зонда с каждой настройкой TTL, а затем выводит на консоль строку, показывающую TTL, адрес шлюза и время прохождения сигнала в обоих направлениях. Если ответы зондирования поступают из разных шлюзов, печатается адрес каждой отвечающей системы. Если в течение пятисекундного интервала ожидания ответа нет (изменяется с -вес флаг), звездочка печатается для этого зонда.
Чтобы предотвратить перегрузку хоста назначения при обработке зондирующего пакета UDP, для порта назначения установлено значение, которое вряд ли будет использоваться этим устройством. Если сеть или служба в пункте назначения использует этот порт, измените значение, используя -п флаг.
Образец использования и вывода вернет результаты, подобные этому примеру:
[як 71]% traceroute nis.nsf.net.
трассировка до nis.nsf.net (35.1.1.48), максимум 30 прыжков, пакет 38 байтов
1 helios.ee.lbl.gov (128.3.112.1) 19 мс 19 мс 0 мс
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 39 мс 19 мс
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 39 мс 19 мс
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 мс 40 мс 39 мс
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 мс 39 мс 39 мс
6 128.32.197.4 (128.32.197.4) 40 мс 59 мс 59 мс
7 131.119.2.5 (131.119.2.5) 59 мс 59 мс 59 мс
8 129.140.70.13 (129.140.70.13) 99 мс 99 мс 80 мс
9 129.140.71.6 (129.140.71.6) 139 мс 239 мс 319 мс
10 129.140.81.7 (129.140.81.7) 220 мс 199 мс 199 мс
11 nic.merit.edu (35.1.1.48) 239 мс 239 мс 239 мс
Вторая и третья строки одинаковы. Этот результат связан с ошибочным ядром в системе второго перехода — lbl-csam.arpa — который пересылает пакеты с нулевым TTL (ошибка в распределенной версии 4.3 BSD). Вы должны угадать, по какому пути проходят пакеты по пересеченной местности, поскольку NSFNet (129.140) не предоставляет трансляции адреса в имя для своих NSS.
Более интересный пример:
[як 72]% traceroute allspice.lcs.mit.edu.
трассировка до allspice.lcs.mit.edu (18.26.0.115), максимум 30 прыжков
1 helios.ee.lbl.gov (128.3.112.1) 0 мс 0 мс 0 мс
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 мс 19 мс 19 мс
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 19 мс 19 мс
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 мс 39 мс 39 мс
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 мс 39 мс 39 мс
6 128.32.197.4 (128.32.197.4) 59 мс 119 мс 39 мс
7 131.119.2.5 (131.119.2.5) 59 мс 59 мс 39 мс
8 129.140.70.13 (129.140.70.13) 80 мс 79 мс 99 мс
9 129.140.71.6 (129.140.71.6) 139 мс 139 мс 159 мс
10 129.140.81.7 (129.140.81.7) 199 мс 180 мс 300 мс
11 129.140.72.17 (129.140.72.17) 300 мс 239 мс 239 мс
12 * * *
13 128,121,54,72 (128,121,54,72) 259 мс 499 мс 279 мс
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 мс 279 мс 279 мс
Обратите внимание, что шлюзы на расстоянии 12, 14, 15, 16 и 17 шагов либо не отправляют ICMP-сообщения «превышено время», либо отправляют их с TTL, слишком маленьким, чтобы связаться с нами. Строки с 14 по 17 работают с кодом шлюза MIT C, который не отправляет сообщения «превышено время».
Тихий шлюз 12 в вышеприведенном примере может быть результатом ошибки в сетевом коде BSD 4. [23] и его производных: машины, использующие код 4.3 и ранее, отправляют недостижимое сообщение, используя любой TTL, оставшийся в исходной дейтаграмме. Для шлюзов оставшийся TTL равен нулю, ICMP «превышено время» гарантированно не вернет нас. Поведение этой ошибки немного интереснее, когда она появляется в системе назначения:
1 helios.ee.lbl.gov (128.3.112.1) 0 мс 0 мс 0 мс
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 19 мс 39 мс
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 мс 39 мс 19 мс
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 мс 40 мс 19 мс
5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 мс 39 мс 39 мс
6 csgw.Berkeley.EDU (128.32.133.254) 39 мс 59 мс 39 мс
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.Berkeley.EDU (128.32.131.22) 59 мс! 39 мс! 39 мс!
Обратите внимание, что существует 12 «шлюзов» (13 — конечный пункт назначения), и последняя половина из них отсутствует. Что действительно происходит, так это то, что сервер с именем rip (Sun-3 под управлением Sun OS 3.5) использует TTL из нашей поступающей датаграммы в качестве TTL в своем ответе ICMP. Таким образом, ответ будет задерживаться на обратном пути (без уведомления, отправленного никому, поскольку ICMP не отправляются для ICMP), пока мы не проверим TTL, который по крайней мере вдвое больше длины пути — другими словами, rip на самом деле только семь прыгает прочь
Ответ, который возвращается с TTL, равным 1, является подсказкой, что эта проблема существует. Traceroute печатает! через некоторое время, если TTL меньше или равен 1. Поскольку поставщики поставляют много устаревшего (DEC Ultrix, Sun 3.x) или нестандартного (HPUX) программного обеспечения, ожидайте частого появления этой проблемы и постарайтесь выбрать целевой хост ваших зондов.
Другие возможные аннотации после времени !ЧАС, !N, или же !п (хост, сеть или протокол недоступны), !S (исходный маршрут не пройден), !F- (необходима фрагментация — отображается значение обнаружения MTU пути RFC1191), !Икс (общение в административном порядке запрещено), !В (нарушение приоритета хоста), !С (приоритет отсечения действует), или ! (ICMP недоступный код). Эти коды определены RFC1812, который заменяет RFC1716. Если почти все зонды приводят к некоторому недоступному хосту, traceroute сдается и завершается.
Эта программа предназначена для использования в тестировании, измерении и управлении сетью. Его следует использовать главным образом для ручной локализации неисправностей. Из-за нагрузки, которая может быть наложена на сеть, неразумно использовать traceroute во время обычных операций или из автоматических скриптов.
