Трассировка команда отображает путь, по которому пакет информации обязуется от своего источника к месту назначения. Одним из способов использования traceroute является обнаружение случаев потери данных в сети, что может указывать на то, что узел не работает.
Поскольку каждый переход в записи отражает новый сервер или маршрутизатор между исходным ПК и предполагаемой целью, проверка результатов сканирования трассировки маршрута выявляет медленные точки, которые могут отрицательно повлиять на сетевой трафик.
Синтаксис traceroute и другая информация, описанная ниже, применима только к машинам Linux. Traceroute по- разному используется в Windows .
Как работает Traceroute
Оценка конкретного маршрута, по которому следует сетевой трафик (или нахождение неверного шлюза, отбрасывающего ваши пакеты), представляет несколько проблем с устранением неполадок. Traceroute использует поле протокола времени жизни IP для запроса ответа ICMP TIME_EXCEEDED от каждого шлюза по пути к хосту назначения .
Единственный параметр, который необходимо указать при выполнении команды traceroute, — это имя хоста или IP-адрес места назначения.
Синтаксис трассировки и переключатели
Синтаксис трассировки в Ubuntu.
Traceroute придерживается следующего общего синтаксиса:
traceroute [-dFInrvx] [-f first_ttl] [-g шлюз] [-i iface] [-m max_ttl] [-p порт] [-q запросов] [-s src_addr] [-t tos] [-w время ожидания] [-z pausemsecs] хост [packagelen]
Производительность или выходные данные команды можно изменить, указав один или несколько дополнительных переключателей.
| Командные переключатели Traceroute | |
|---|---|
| переключатель | объяснение |
| -f | Установите начальное время жизни, используемое в первом исходящем тестовом пакете. |
| -F | Установите бит «не фрагментировать». |
| -d | Включить отладку на уровне сокетов. |
| -грамм | Укажите свободный исходный шлюз маршрута (максимум 8). |
| -я | Укажите сетевой интерфейс для получения IP-адреса источника для исходящих тестовых пакетов. Обычно это полезно только на многосетевом хосте. (Смотрите флаг -s для другого способа сделать это.) |
| -Я | Используйте ICMP ECHO вместо дейтаграмм UDP . |
| -m | Установите максимальное время жизни (максимальное количество прыжков), используемое в исходящих тестовых пакетах. По умолчанию используется 30 переходов (то же самое, что используется по умолчанию для соединений TCP). |
| -n | Распечатывать адреса переходов численно, а не символически и численно (сохраняет поиск адреса к имени сервера имен для каждого шлюза, найденного на пути). |
| -п | Установите базовый номер порта UDP, используемый в пробниках (по умолчанию 33434). Трассировка надеется , что ничего не прослушивает UDP портов базы для базового + nhops — 1 на хосте назначения (так что сообщение ICMP PORT_UNREACHABLE будет возвращено прекратить маршрут трассировки). Если что-то прослушивает порт в диапазоне по умолчанию, этот параметр можно использовать для выбора неиспользуемого диапазона портов. |
| -р | Обходите обычные таблицы маршрутизации и отправьте напрямую на хост в подключенной сети. Если хост не находится в сети с прямым подключением, возвращается ошибка. Эта опция может использоваться для проверки связи с локальным хостом через интерфейс, у которого нет маршрута через него (например, после того, как интерфейс был сброшен маршрутизируемым (8C)). |
| -s | Используйте следующий IP-адрес (который обычно задается как IP-номер, а не имя хоста) в качестве адреса источника в исходящих тестовых пакетах. На многодомных хостах (с более чем одним IP-адресом) этот параметр можно использовать, чтобы заставить исходный адрес быть чем-то отличным от IP-адреса интерфейса, на который отправляется тестовый пакет. Если IP-адрес не является одним из адресов интерфейса этого аппарата, возвращается ошибка и ничего не отправляется. (Смотрите флаг -i для другого способа сделать это.) |
| -t | Установите для типа обслуживания в тестовых пакетах следующее значение (по умолчанию ноль). Значение должно быть десятичным целым числом в диапазоне от 0 до 255. Этот параметр можно использовать, чтобы увидеть, приводят ли разные типы обслуживания к различным путям. (Если вы не используете 4.4bsd, это может быть академическим, так как обычные сетевые сервисы, такие как telnet и ftp, не позволяют вам контролировать TOS.) Не все значения TOS являются законными или значимыми — см. Определения IP-спецификации. Полезные значения: ` -t 16 ‘(низкая задержка) и` -t 8 ‘ (высокая пропускная способность). |
| -v | Подробный вывод. Полученные ICMP-пакеты, отличные от TIME_EXCEEDED и UNREACHABLE, перечислены. |
| -w | Установите время (в секундах) ожидания ответа на зонд (по умолчанию 5 секунд). |
| -Икс | Переключить контрольные суммы IP . Обычно это не позволяет traceroute вычислять контрольные суммы IP. В некоторых случаях операционная система может перезаписывать части исходящего пакета, но не пересчитывать контрольную сумму; таким образом, в некоторых случаях по умолчанию не вычисляются контрольные суммы, а использование -x приводит к их вычислению. Обратите внимание, что контрольные суммы обычно требуются для последнего прыжка при использовании пробников ICMP ECHO ( -I ), поэтому они всегда рассчитываются при использовании ICMP. |
| -z | Установите время (в миллисекундах) для паузы между датчиками (по умолчанию 0). Некоторые системы, такие как Solaris и маршрутизаторы от Cisco, ограничивают скорость передачи сообщений icmp. Хорошее значение для использования это 500 (например, 1/2 секунды). |
Интерпретация результатов
Traceroute обрисовывает путь, по которому IP-пакет следует к интернет-хосту, запуская тестовые пакеты UDP с небольшим TTL, а затем прослушивая ICMP-ответ «превышено время» от шлюза. Запустите тестирование с TTL, равным единице, и увеличивайте на единицу, пока не получите ICMP «порт недоступен» (что означает, что пакет прибыл в пункт назначения) или не достигните максимального значения попыток, которое по умолчанию составляет 30 прыжков и может быть изменено с помощью — м флаг.
Когда traceroute выполняется, он отправляет три зонда с каждой настройкой TTL, а затем выводит на консоль строку, показывающую TTL, адрес шлюза и время прохождения сигнала в обоих направлениях. Если ответы зондирования поступают из разных шлюзов, печатается адрес каждой отвечающей системы. Если в течение пятисекундного интервала ожидания ответа нет (изменяется с помощью флага -w ), для этого зонда печатается звездочка.
Чтобы предотвратить перегрузку хоста назначения при обработке зондирующего пакета UDP, для порта назначения установлено значение, которое вряд ли будет использоваться этим устройством. Если сеть или служба в пункте назначения использует этот порт, измените значение с помощью флага -p .
Пример использования и вывода вернет результаты, похожие на этот пример:
[як 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 куб. -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.
traceroute to 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) программного обеспечения, ожидайте частого появления этой проблемы и постарайтесь выбрать целевой хост ваших зондов.
Другие возможные аннотации после времени являются ! H , N! Или P! (Хост, сеть или протокол недостижим) ! S (источник маршрут не удался), ! F- (отображается фрагментация необходимо, RFC1191 Path значение MTU Discovery) , ! X (связь административно запрещена) ,! V (нарушение приоритета хоста) ,! C (ограничение приоритета действует) или ! (ICMP недоступный код). Эти коды определены RFC1812, который заменяет RFC1716. Если почти все зонды приводят к некоторому недоступному хосту, traceroute сдается и завершается.
Эта программа предназначена для тестирования, измерения и управления сетью. Его следует использовать главным образом для ручной локализации неисправностей. Из-за нагрузки, которая может быть наложена на сеть, неразумно использовать traceroute во время обычных операций или из автоматических сценариев.