Что такое traceroute на роутере

Для большинства поставщиков управляемых услуг (MSP), системных администраторов и технических специалистов, команды Traceroute и Tracert являются первыми сигналами для устранения неполадок, связанных с задержкой ​​сети или проблемами с подключением. Но что это?

Что такое Traceroute и Tracert

Traceroute или Tracert – это утилита, служащая для диагностики сети. Она отслеживает пути, по которым пакеты данных проходят от источника к хосту назначения, что позволяет администраторам оперативно решить проблемы с подключением.

В Windows эта команда называется Tracert, а в Linux и MacOS – Traceroute.

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

Traceroute сопоставляет каждый переход, предоставляет подробную информацию и время приёма-передачи (RTT), а также, по возможности, сообщает имя устройства и IP-адрес.

В то время как команда Ping может сообщить, есть ли проблема, Traceroute поможет вам точно определить, где именно она образовалась.

Представьте, что вы посещаете веб-сайт, и его страницы долго загружаются. В этом случае вы можете использовать Traceroute, чтобы определить, где происходят самые длительные задержки, чтобы добраться до источника самого сбоя.

Как работает Traceroute и Tracert?

1. По протоколу UDP (User Datagram Protocol – «протокол пользовательских датаграмм») Traceroute отправляет последовательность IP-пакетов. Всего таких пакетов по умолчанию может быть 3.
2. Первый пакет имеет время жизни (также известное как TTL (Time To Live) или лимит переходов), равное 1, второй пакет имеет TTL=2 и так далее.
3. Каждый раз, когда пакет передается новому маршрутизатору, TTL уменьшается на 1. Это сделано для предотвращения проблем с зацикливанием между серверами. Если бы не было TTL, пакет мог бы бесконечно долго перебрасываться между серверами.

Когда время жизни достигает 0, пакет отбрасывается, а маршрутизатор возвращает сообщение об ошибке. Отправляя пакеты таким образом, Traceroute гарантирует, что каждый маршрутизатор на пути отклонит пакет и отправит ответ.

Всё о трассировке

Что такое трассировка?

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

Данные трассировки помогают понять поток запросов и определить, где в системе возникают сбои или проблемы с производительностью и почему.

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

Хотя трассировки существуют уже давно, тенденция к распределённым архитектурам, микросервисам и контейнеризации сделала их важной частью большой системы наблюдения. Ведь наличие механизма, позволяющего понять поток данных, необходимо для обслуживания серверов и устранения неполадок.

Трассировка, наряду с журналами и метриками, занимает важное место в системе. В то время как журналы предоставляют сведения о конкретных событиях, таких как обращение к базе данных и запись в файл или сообщение об ошибке, трассировка соединяет цепочку связанных событий.

Одна трассировка маршрута даёт представление о:

• каждом шаге, через который прошёл запрос;
• количестве времени, затраченном на каждое действие;
• общем времени, которое понадобилось на его обработку.

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

Эта информация бесценна для отладки сложных проблем и оптимизации вашей системы.

Как работает трассировка?

Прежде чем перейти к трассировке, важно узнать, что приложения могут быть монолитными или микросервисными.

Монолитное приложение разрабатывается как единый функциональный модуль, в то время как приложение с микросервисной архитектурой разбивается на модульные службы, каждая из которых выполняет основную функцию приложения и часто управляется специальной командой.

Микросервисы используются для создания многих современных приложений, поскольку они упрощают тестирование и развёртывание быстрых обновлений, а также предотвращают возникновение единой точки отказа.

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

Используя трассировку, разработчики могут визуализировать весь путь запроса – от интерфейса к серверу – и точно определить любые сбои производительности, которые возникают на этом пути.

Платформы трассировки начинают собирать данные в момент подачи запроса. Например, когда пользователь отправляет форму на веб-сайте. Это создаёт уникальный идентификатор трассировки.

Этот процесс позволяет идентифицировать каждый запрос, вызов и процесс и соответствующим образом расставлять приоритеты в своих усилиях по устранению неполадок.

Для получения результатов трассировки в том числе используются команды Traceroute и Tracert.

Разница между Traceroute и Tracert

Принцип работы у Traceroute и Tracert один, однако разница между ними состоит не только в операционных системах.

Напоминаем, что команда Tracert обслуживает Windows, а Traceroute работает на Linux и MacOS.

Tracert

1. Tracert, в отличие от своего Linux-двойника, реализован на основе протокола ICMP, а не UDP.
2. Tracert отправляет эхо-запрос ICMP (ICMP Echo Request) с TTL=1.
3. Первый маршрутизатор проверяет адрес назначения, чтобы выяснить был ли отправлен запрос именно ему.
4. Узнав, что цель пакета – другой хост, маршрутизатор отбрасывает его, и TTL становится равным 0.
5. Затем маршрутизатор 1 отправляет ICMP-сообщение с указанием информации о себе и причине проблемы источнику пакета: «Time-To-Live Exceeded» или «Time Exceeded in transit».
6. Благодаря этому сообщению Tracert записывает маршрутизатор 1 как первый транзитный участок или, как его ещё называют, «хоп, прыжок».

Процесс передачи пакета между промежуточными маршрутизаторами продолжится, пока переменная (TTL ICMP-запроса), не станет равна количеству «прыжков» между узлом-отправителем и узлом-получателем, и пакет не будет получен хостом назначения или количество сетевых переходов не превысит максимальное значение для Tracert – 30.

1. Когда целевой хост проверит IP-адрес назначения и узнает, что запрос был направлен именно ему, он отправит эхо-ответ ICMP (ICMP Echo Request), что даст утилите понять, что процесс передачи завершён.

Traceroute

В чём ещё отличие Traceroute от Tracert? В Traceroute схема схожая, практически идентичная.

Целевому хосту направляется фрагментированный UDP-запрос. Таким образом, отправляется сразу несколько пакетов с TTL: TTL=1, TTL=2 и TTL=3.

Вот только раз эта утилита не отправляет эхо-запрос ICMP, как она понимает, что трассировка подошла к концу?

Всё просто: в каждом пакете содержатся данные о порте отправителя (Source) и порте получателя (Destination). Destination порт по умолчанию закрытый (34434), поэтому утилита Traceroute сразу понимает, что процесс передачи данных завершён, когда получает ответ с сообщением о недоступности порта «Destination port unreachable» (Хост/Порт недостижим). Иными словами, запрос достиг целевого хоста.

Как использовать Traceroute и Tracert?

В основном пользователи могут использовать команду Traceroute или Tracert через обычную командную строку. Однако точный метод его запуска зависит от операционной системы компьютера.

Давайте посмотрим, как запустить команду Traceroute или Tracert в Windows, Linux и macOS.

Tracert – Windows

1. Перейдите в меню Пуск.
2. Выберите Выполнить.
3. Введите cmd и нажмите ОК. Это откроет командную строку.
4. Введите команду tracert и затем впишите имя хоста или IP-адрес назначения. Пример: tracert www.nic.ru
5. Нажмите Enter.

Traceroute – Linux

1. Откройте приложение Терминал. Это можно сделать при помощи сочетания клавиш CTRL + Shift + T.
2. Впишите команду traceroute вместе с именем хоста или IP-адресом. Пример: traceroute www.nic.ru
3. Нажмите Enter.

Traceroute – MacOS

Раньше это действие можно было выполнить через встроенное приложение Сетевая утилита, но на данный момент она не поддерживается компанией Apple. Поэтому:

1. Запустите приложение Терминал.
2. Введите команду traceroute и имя хоста или IP-адрес назначения. Пример: traceroute www.nic.ru
3. Нажмите Enter.

Также можно добавить дополнительные параметры в команду Traceroute или Tracert, чтобы сделать ваши результаты более точными. Вот некоторые расширенные параметры трассировки:

Как читать результаты Tracert

После выполнения команды Tracert или Traceroute система представит результаты в виде множества строк. Отчёт может несколько отличаться в зависимости от вашей операционной системы, но обычно он содержит одну и ту же информацию.

Стандартные результаты Tracert или Traceroute включают в себя несколько строк, описывающих каждый переход, который проходит пакет для достижения хоста назначения. Каждая строка разделена на столбцы с различной информацией.

Давайте рассмотрим каждый столбец и его детали.

Число хопов – первый столбец количество сделанных “прыжков”.

IP-адрес или имя хоста – этот столбец раскрывает IP-адрес или имя хоста устройства на этом конкретном переходе.

RTT – это круговая задержка или время приёма-передачи, которое показывает, сколько времени требуется каждому пакету, чтобы достичь определенного IP-адреса и вернуться на ваш компьютер. Существует три разных столбца RTT, так как Traceroute по умолчанию отправляет три UDP-пакета.

Если время трассировки истекает на определенном узле, это может означать, что в данном месте возникла проблема или что маршрут неверен, что не позволяет пакету достичь пункта назначения. В результатах это представлено как:

Заключение

Команда Traceroute и Tracert – это полезный и простой в использовании инструмент диагностики сети. Как правило, это ещё и первый способ устранения неполадок с подключением.

В этой статье вы узнали, чем эта утилита может отличаться в зависимости от вашей операционной системы, как использовать команду и читать полученные результаты.

Introduction

The traceroute command allows you to determine the path a packet takes in order to get to a destination from a given source by returning the sequence of hops the packet has traversed. This utility comes with your host operating system (for example, Linux or Microsoft (MS) Windows), as well as with Cisco IOS® Software.

Prerequisites

Requirements

Readers of this document should have basic knowledge of one of these operating systems:

• Cisco IOS Software

• Linux

• Microsoft Windows

Components Used

The information in this document applies to these software and hardware versions:

• Cisco Router that runs Cisco IOS Software Release 12.2(27)

• PC that runs Red Hat Linux version 9

• PC that runs MS Windows 2000

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

General Operation

If you execute the traceroute ip-address command on a source device (such as a host, or a router acting as a host), it sends IP packets toward the destination with Time To Live (TTL) values that increment up to the maximum specified hop count. This is 30 by default. Typically, each router in the path towards the destination decrements the TTL field by one unit while it forwards these packets. When a router in the middle of the path finds a packet with TTL = 1, it responds with an Internet Control Message Protocol (ICMP) «time exceeded» message to the source. This message lets the source know that the packet traverses that particular router as a hop

There are some differences with the way the traceroute command is implemented in the various operating systems this document discusses.

Cisco IOS and Linux

The TTL for the initial User Datagram Protocol (UDP) datagram probe is set to 1 (or the minimum TTL, as specified by user in the extended traceroute command. The destination UDP port of the initial datagram probe is set to 33434 (or as specified in the extended traceroute command output). The extended traceroute command is a variation of the ordinary traceroute command which allows the default values of the parameters used by the traceroute operation such as TTL and destination port number to be modified. For more information on how to use the extended traceroute command, refer to Using the Extended ping and Extended traceroute Commands. The source UDP port of the initial datagram probe is randomized and has logical operator OR with 0x8000 (ensures a minimum source port of 0x8000). These steps illustrate what happens when the UDP datagram is launched:

Note: The parameters are configurable. This example starts with n = 1 and finishes with n = 3.

1. The UDP datagram is dispatched with TTL = 1, destination UDP port= 33434, and the source port randomized.

2. The UDP destination port is incremented, the source UDP port is randomized, and the second datagram dispatched.

3. Step 2 is repeated for up to three probes (or as many times as requested in an extended traceroute command output). For each of the probes sent, you receive a «TTL exceeded» message, which is used to build a step-by-step path to the destination host.

4. TTL is incremented, and this cycle repeats with incremental destination port numbers, if the ICMP «time exceeded» message is received. You can also get one of these messages:

   • An ICMP type 3, code 3 («destination unreachable,» «port unreachable») message, which indicates that a host has been reached.

   • A «host unreachable,» «net unreachable,» «maximum TTL exceeded,» or a «timeout» type of message, which means that the probe is resent.

Cisco routers send UDP probe packets with a random source port and an incremental destination port (to distinguish the different probes). Cisco routers send the ICMP message «time exceeded» back to the source from where the UDP/ICMP packet was received.

The Linux traceroute command is similar to the Cisco router implementation. However, it uses a fixed source port. The -n option in the traceroute command is used to avoid a request to a name server.

Microsoft Windows

The MS Windows tracert command uses ICMP echo request datagrams instead of UDP datagrams as probes. ICMP echo requests are launched with incrementing TTL, and the same operation as described in Cisco IOS and Linux occurs. The significance of using ICMP echo request datagrams is that the final hop does not rely on the response of an ICMP «unreachable» message from the destination host. It relies instead on an ICMP echo reply message.

The command syntax is:

tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name

This table explains the command parameters:

ICMP Unreachables Rate Limitation

ICMP unreachables are limited to one packet per 500 ms (as a protection for Denial of Service (DoS) attacks) in a Cisco Router. From Cisco IOS Software Release 12.1 and later, this rate value is configurable. The command introduced is:

ip icmp rate-limit unreachable
 [DF] <1-4294967295 millisecond>
 
no ip icmp rate-limit unreachable [DF] (DF limits rate for code=4) 

Refer to Cisco bug ID CSCdp28161 (registered customers only) for further details.

This limitation is for the aggregate rate of all the ICMP unreachables, as this output shows. Refer to RFC 792 for more information.

type = 3, code 
0 = net unreachable; 
1 = host unreachable; 
2 = protocol unreachable; 
3 = port unreachable; 
4 = fragmentation needed and DF set; 
5 = source route failed.

This limitation does not affect other packets like ICMP echo requests or ICMP «time exceeded» messages.

Examples

This network topology is used for the examples:

In each of the three examples, a different Device A is used. From Device A, the traceroute 150.1.4.2 command is executed to Device 7C.

In each of the examples, the debug ip packet detail command runs on Device 11A.

Cisco Router with Cisco IOS Software

This extended traceroute command example shows the options you can change when you execute a traceroute command from a Cisco router. In this example, everything is left default:

rp-10c-2611#traceroute
Protocol [ip]: 
Target IP address: 150.1.4.2 
Source address: 150.1.1.1 
Numeric display [n]: 
Timeout in seconds [3]: 
Probe count [3]: 
Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 150.1.4.2

1 150.1.1.2 4 msec 0 msec 4 msec
2 150.1.2.2 4 msec 4 msec 0 msec
3 150.1.3.2 0 msec 0 msec 4 msec
4 150.1.4.2 4 msec * 0 msec 


rp-11a-7204#
*Dec 29 13:13:57.060: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.060: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.064: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.068: ICMP type=11, code=0

In this debug output, Device 11A sends ICMP «time exceeded» messages to the source of the probes (150.1.1.1). These ICMP messages are in response to the initial probes that had a TTL=1. Device 11A decrements the TTL to zero, and responds with the «time exceeded» messages.

Note:  You do not see the UDP probes in this debug output for two reasons:

• Device 11A is not the destination of the UDP probes.

• The TTL is decremented to zero, and the packet is never routed. Therefore, the debug never recognizes the packet.

  *Dec 29 13:13:57.068: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
   g=150.1.2.2, len 28, forward
  *Dec 29 13:13:57.068: UDP src=40309, dst=33437
  *Dec 29 13:13:57.068: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Dec 29 13:13:57.068: ICMP type=11, code=0
  *Dec 29 13:13:57.072: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
   g=150.1.2.2, len 28, forward
  *Dec 29 13:13:57.072: UDP src=37277, dst=33438
  *Dec 29 13:13:57.072: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Dec 29 13:13:57.072: ICMP type=11, code=0
  *Dec 29 13:13:57.076: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
   g=150.1.2.2, len 28, forward
  *Dec 29 13:13:57.076: UDP src=36884, dst=33439
  *Dec 29 13:13:57.076: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Dec 29 13:13:57.076: ICMP type=11, code=0

This debug output shows the UDP probe from source 150.1.1.1 destined to 150.1.4.2.

Note:  In these probes the TTL=2 (this cannot be seen with debug). Device 11A decrements the TTL to 1 and forwards the UDP packets onto Device 7A. Device 7A decrements the TTL to zero, and responds with ICMP «time exceeded» messages.

*Dec 29 13:13:57.080: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 28, forward
*Dec 29 13:13:57.080: UDP src=37479, dst=33440
*Dec 29 13:13:57.080: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 13:13:57.080: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 28, forward
*Dec 29 13:13:57.084: UDP src=40631, dst=33441
*Dec 29 13:13:57.084: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 13:13:57.084: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39881, dst=33442
*Dec 29 13:13:57.088: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 13:13:57.088: ICMP type=11, code=0

You see the next three UDP probes in this debug output. The TTL for these probes is 3. Device 11A decrements the TTL to 2 and forwards them on to Device 7A. Device 7A decrements the TTL to 1 and forwards the packets on to Device 7B, which decrements the TTL to zero and responds with ICMP «time exceeded» messages.

*Dec 29 13:13:57.088: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39217, dst=33443
*Dec 29 13:13:57.092: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 13:13:57.092: ICMP type=3, code=3
*Dec 29 13:13:57.092: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 28, forward
*Dec 29 13:13:57.096: UDP src=34357, dst=33444
*Dec 29 13:14:00.092: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 28, forward
*Dec 29 13:14:00.092: UDP src=39587, dst=33445
*Dec 29 13:14:00.092: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 13:14:00.092: ICMP type=3, code=3

You can see the last three UDP probes in this debug output. The original TTL of these probes was 4. The TTL was decremented to 3 by Device 11A, then decremented to 2 by Device 7A, then decremented to 1 by Device 7B. Device 7C responds with ICMP «port unreachable» messages, since it was the destination of the probes.

Note: Device 7C only sends two ICMP «port unreachable» messages because of the rate limitation.

PC with Linux

[root#linux-pc]#traceroute -n 150.1.4.2
traceroute to 150.1.4.2 (150.1.4.2), 30 hops max, 40 byte packets
1. 150.1.1.2 1.140 ms 0.793 ms 0.778 ms
2. 150.1.2.2 2.213 ms 2.105 ms 3.491 ms
1. 150.1.3.2 3.146 ms 2.314 ms 2.347 ms
1. 150.1.4.2 3.579 ms * 2.954 ms 


rp-11a-7204#
*Jan 2 07:17:27.894: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0

In this debug output, Device 11A sends ICMP «time exceeded» messages to the source of the probes (150.1.1.1). These ICMP messages are in response to the initial probes that had a TTL=1. Device 11A decrements the TTL to zero, and responds with the «time exceeded» messages.

Note: You do not see the UDP probes in this debug output for two reasons:

• Device 11A is not the destination of the UDP probes.

• The TTL is decremented to zero, and the packet is never routed. Therefore, the debug never recognizes the packet.

  *Jan 2 07:17:27.894: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
   g=150.1.2.2, len 40, forward
  *Jan 2 07:17:27.894: UDP src=33302, dst=33438
  *Jan 2 07:17:27.898: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Jan 2 07:17:27.898: ICMP type=11, code=0
  *Jan 2 07:17:27.898: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
   g=150.1.2.2, len 40, forward
  *Jan 2 07:17:27.898: UDP src=33302, dst=33439
  *Jan 2 07:17:27.898: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Jan 2 07:17:27.898: ICMP type=11, code=0
  *Jan 2 07:17:27.898: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
   g=150.1.2.2, len 40, forward
  *Jan 2 07:17:27.898: UDP src=33302, dst=33440
  *Jan 2 07:17:27.902: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Jan 2 07:17:27.902: ICMP type=11, code=0

Note: In this debug output, you now see the UDP probe from source 150.1.1.1 destined to 150.1.4.2.

Note: In these probes the TTL=2 (this cannot be seen with debug). Device 11A decrements the TTL to 1 and forwards the UDP packets onto Device 7A. Device 7A decrements the TTL to zero, and responds with ICMP «time exceeded» messages.

*Jan 2 07:17:27.902: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.1.2.2, len 40, forward
*Jan 2 07:17:27.902: UDP src=33302, dst=33441
*Jan 2 07:17:27.906: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Jan 2 07:17:27.906: ICMP type=11, code=0
*Jan 2 07:17:27.906: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.1.2.2, len 40, forward
*Jan 2 07:17:27.906: UDP src=33302, dst=33442
*Jan 2 07:17:27.910: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0
*Jan 2 07:17:27.910: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33443
*Jan 2 07:17:27.910: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0

The next three UDP probes are now seen in this debug output. The TTL for these probes is 3. Device 11A decrements the TTL to 2 and forwards them on to Device 7A. Device 7A decrements the TTL to 1 and forwards the packets on to Device 7B, which decrements the TTL to zero and responds with ICMP «time exceeded» messages.

*Jan 2 07:17:27.910: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33444
*Jan 2 07:17:27.914: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Jan 2 07:17:27.914: ICMP type=3, code=3
*Jan 2 07:17:27.914: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.1.2.2, len 40, forward
*Jan 2 07:17:27.914: UDP src=33302, dst=33445
*Jan 2 07:17:32.910: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.1.2.2, len 40, forward
*Jan 2 07:17:32.910: UDP src=33302, dst=33446
*Jan 2 07:17:32.914: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Jan 2 07:17:32.914: ICMP type=3, code=3

This debug output shows the last three UDP probes. The original TTL of these probes was 4. The TTL was decremented to 3 by Device 11A, then decremented to 2 by Device 7A, then decremented to 1 by Device 7B. Device 7C then responds with ICMP «port unreachable» messages, since it was the destination of the probes.

Note: Device 7C only sends two ICMP «port unreachable» messages because of the rate limiting.

PC with MS Windows

C:\>tracert 150.1.4.2 

1 <10 ms <10 ms <10 ms 10.1.1.2
1 <10 ms <10 ms <10 ms 10.1.2.2
1 <10 ms <10 ms <10 ms 10.1.3.2
1 <10 ms 10 ms 10 ms 10.1.4.2

Trace complete

rp-11a-7204#
*Dec 29 14:02:22.236: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 78, forward
*Dec 29 14:02:22.236: UDP src=137, dst=137
*Dec 29 14:02:22.240: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 14:02:22.240: ICMP type=3, code=3
*Dec 29 14:02:23.732: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 78, forward
*Dec 29 14:02:23.732: UDP src=137, dst=137
*Dec 29 14:02:23.736: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 14:02:23.736: ICMP type=3, code=3
*Dec 29 14:02:25.236: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 78, forward
*Dec 29 14:02:25.236: UDP src=137, dst=137
*Dec 29 14:02:25.236: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 14:02:25.240: ICMP type=3, code=3
*Dec 29 14:02:26.748: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.748: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0

In this debug output, Device 11A sends ICMP «time exceeded» messages to the source of the probes (150.1.1.1). These ICMP messages are in response to the initial probes, which are ICMP echo request packets with a TTL=1. Device 11A decrements the TTL to zero and responds with the ICMP messages.

Note: At the top you see the NETBIOS name requests. These requests are seen as UDP packets with source and destination ports of 137. For clarity reasons, the NETBIOS packets are removed from the rest of the debug output. You can use the -d option in the tracert command to disable the NETBIOS behavior.

Note: You do not see the ICMP probes in this debug output for two reasons:

• Device 11A is not the destination of the ICMP probes.

• The TTL is decremented to zero, and the packet is never routed. Therefore, the debug never recognizes the packet.

  *Dec 29 14:02:32.256: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
   g=150.1.2.2, len 92, forward
  *Dec 29 14:02:32.256: ICMP type=8, code=0
  *Dec 29 14:02:32.260: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Dec 29 14:02:32.260: ICMP type=11, code=0
  *Dec 29 14:02:32.260: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
   g=150.1.2.2, len 92, forward
  *Dec 29 14:02:32.260: ICMP type=8, code=0
  *Dec 29 14:02:32.260: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Dec 29 14:02:32.260: ICMP type=11, code=0
  *Dec 29 14:02:32.264: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
   g=150.1.2.2, len 92, forward
  *Dec 29 14:02:32.264: ICMP type=8, code=0
  *Dec 29 14:02:32.264: IP: s=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
   g=150.1.1.1, len 56, forward
  *Dec 29 14:02:32.264: ICMP type=11, code=0

In this debug output, you now see the ICMP probe from source 150.1.1.1 destined to 150.1.4.2.

Note: In these probes, the TTL=2 (this cannot be seen with debug). Device 11A decrements the TTL to 1 and forwards the UDP packets on to Device 7A. Device 7A decrements the TTL to zero, and responds with ICMP «time exceeded» messages.

*Dec 29 14:02:37.776: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 92, forward
*Dec 29 14:02:37.776: ICMP type=8, code=0
*Dec 29 14:02:37.776: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 14:02:37.776: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.780: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 14:02:37.780: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.784: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 14:02:37.784: ICMP type=11, code=0

You see the next three ICMP probes in this debug output. The TTL for these probes is 3. Device 11A decrements the TTL to 2 and forwards them on to Device 7A. Device 7A decrements the TTL to 1 and forwards the packets on to Device 7B, which decrements the TTL to zero and responds with ICMP «time exceeded» messages.

*Dec 29 14:02:43.292: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 92, forward
*Dec 29 14:02:43.292: ICMP type=8, code=0
*Dec 29 14:02:43.296: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 92, forward
*Dec 29 14:02:43.296: ICMP type=0, code=0
*Dec 29 14:02:43.296: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 92, forward
*Dec 29 14:02:43.296: ICMP type=8, code=0
*Dec 29 14:02:43.300: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 92, forward
*Dec 29 14:02:43.300: ICMP type=0, code=0
*Dec 29 14:02:43.300: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.1.2.2, len 92, forward
*Dec 29 14:02:43.300: ICMP type=8, code=0
*Dec 29 14:02:43.304: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 92, forward
*Dec 29 14:02:43.304: ICMP type=0, code=0

This debug output shows the last three ICMP probes. The original TTL of these probes was 4. The TTL was decremented to 3 by Device 11A, then decremented to 2 by Device 7A, then decremented to 1 by Device 7B. Device 7C then responds with ICMP echo reply messages (type=0, code=0), since it was the destination of the probes.

Note: The ICMP echo reply messages are not rate limited as the ICMP «port unreachable» messages were. In this case, you see all three ICMP echo reply messages sent.

Additional Notes

In Cisco routers, the codes for a traceroute command reply are:

! -- success
* -- time out
N -- network unreachable
H -- host unreachable
P -- protocol unreachable
A -- admin denied
Q -- source quench received (congestion)
? -- unknown (any other ICMP message)

If you run the traceroute command from UNIX, note these items:

• You can receive «traceroute: icmp socket: Permission denied» messages.

• The traceroute program relies on the Network Interface Tap (NIT) to snoop in the network. This device is only accessible by root. You must either run the program as root, or set the user ID for root.

Summary

This document has demonstrated how the traceroute command determines the path a packet takes from a given source to a given destination with the use of UDP and ICMP packets. The possible types of ICMP messages in the outputs are:

• If the TTL is exceeded in transit, type=11, code=0, then the packet is sent back by the transit router in all the cases where the TTL of the probe packets expires before the packets reach the destination.

• If the port is unreachable, type=3, code=3, then the packet is sent back in response to the UDP probe packets when they reach the destination (the UDP application is not defined). These packets are limited to one packet per 500 ms. This explains why the response from the destination (see the outputs for the Cisco router and Linux) failed in the even responses. Device 7C does not generate the ICMP message, and the traceroute command output in each device waits for more than one second. In the case of the MS Windows tracert command output, the ICMP message is generated because the UDP port 137 does not exist in a Cisco router.

• If there is an echo, type=8, code=0, then the echo probe packet is sent by the MS Windows PC.

• If there is an echo reply, type=0, code=0, then a reply to the previous packet is sent when the destination is reached. This only applies to the MS Windows tracert command.

Related Information

• Technical Support & Documentation — Cisco Systems

Содержание:

• Что такое Traceroute?
• Как работает Traceroute?
• Как использовать Traceroute NG?

Проблемы с подключением очень распространены в этом цифровом мире. Когда мы пытаемся подключиться к другим серверам или машинам, наши компьютеры обмениваются данными друг с другом. Эта коммуникация осуществляется по частям, известным как пакеты. Отправка и получение пакетов зависит от вашего интернет-соединения. Обычно это происходит на очень высокой скорости (учитывая скорости современного мира), и поэтому большинство из нас часто не знают, что происходит на задней стороне. Когда эти пакеты не могут достичь места назначения с хост-машины, вы не сможете установить соединение. Traceroute — это базовый диагностический инструмент, который очень полезен в таких условиях. Давайте обсудим его в деталях.

Что такое Traceroute?

Трассировка — это очень полезный и интересный инструмент, который вы можете использовать, чтобы выяснить, как пакеты передаются от хост-устройства к целевой машине. В Интернете пакеты, передаваемые с вашего компьютера на целевой компьютер, будут обрабатываться различными маршрутизаторами. Эти маршрутизаторы передают пакеты от одного к другому, пока пакет, наконец, не достигнет пункта назначения. Эти маршрутизаторы, конечно же, имеют свои IP-адреса, поскольку они могут передавать пакеты. Трассировка работает очень хитро. Для этого используется поле в заголовке IP-пакета, известное как TTL или Time to Live.

TTL используется для предотвращения зацикливания пакетов. Допустим, сеть неправильно сконфигурирована, и поэтому пакет попадает в эту неправильную конфигурацию, заставляя его курсировать туда-сюда между двумя маршрутизаторами. Если бы не TTL, пакет застрял бы навсегда, потребляя ресурсы сети. Как это работает, перед отправкой пакета ему присваивается определенное значение TTL, скажем, 4. Когда пакет достигает первого маршрутизатора, он теряет свое значение на 1, что означает уменьшение значения Time to Live. Как только значение достигает 0, пакет отбрасывается, что позволяет предотвратить зацикливание.

Как работает Traceroute?

Таким образом, traceroute использует это поле TTL, чтобы выяснить IP-адреса маршрутизаторов на пути маршрутизации. Как он это делает, спросите вы? Чтобы найти идентификаторы маршрутизаторов, traceroute посылает пакет со значением TTL 1, который при касании маршрутизатора отбрасывается, поскольку его значение уменьшается до нуля. В ответ маршрутизатор посылает сообщение источнику, информируя его об этом. Traceroute использует это сообщение или ping для выяснения идентификации маршрутизатора. Значение пакета продолжает увеличиваться на единицу, в результате чего traceroute получает IP-адреса всех маршрутизаторов на пути маршрутизации. Таким образом, вы получаете анализ пути соединения. Эта информация может быть использована для диагностики проблем подключения сетевыми администраторами и является полезной.

Как использовать Traceroute NG?

Traceroute NG это улучшенный инструмент traceroute, разработанный компанией Solarwinds, который можно использовать для диагностики проблем с подключением. Он предлагает быстрый и точный анализ сетевого пути с использованием TCP и ICMP зондирования. Мы расскажем вам, как пользоваться этим инструментом, и, честно говоря, это довольно просто. Чтобы воспользоваться инструментом, сначала необходимо загрузить его с сайта Solarwinds. Для этого перейдите по ссылке эта ссылка и нажмите на ‘Скачать бесплатный инструмент‘. После того как инструмент загрузится, следуйте инструкциям, приведенным ниже:

1. Распакуйте скачанный .zip файл в любое удобное для вас место, а затем перейдите в указанное место.
2. Запустить traceng.exe файл для запуска traceroute NG.
3. Когда вы запустите инструмент, вам будет предложено перейти по Лицензионное соглашение коробка. Согласитесь с соглашением, а затем нажмите Принять.
   
4. Если у вас нет WinPcap в вашей системе, traceroute автоматически загрузит мастер установки WinPcap. При появлении запроса с UAC диалоговое окно, нажмите Да.
5. Установить WinPcap пройдя через мастер установки.
   
6. Как только это будет сделано, откройте Командная строка Traceroute NG окно. Вам будут показаны все доступные параметры и описание требований.
7. Существует множество параметров, которые вы можете использовать при трассировке.
   
8. Вы можете использовать -a параметр предпринять одно из указанных действий при изменении пути.
9. Если вы хотите создать файл журнала, воспользуйтесь командой -параметр l что приведет к созданию файла журнала анализа пути. Это избавит вас от необходимости вручную записывать все IP-адреса, если вы этого хотите, автоматически сохраняя их в лог-файле. Журналы будут сохранены в ‘журналы‘ папку traceroute.
10. Чтобы воспользоваться инструментом, просто укажите URL любого веб-сайта, затем любые параметры, которые вы хотите, и нажмите кнопку Введите.
    
11. Во время traceroute, если возникают какие-либо проблемы, они будут отображаться перед Вопросы.
    
12. Если вы хотите остановить traceroute, просто введите ‘q‘ без апострофов и нажмите Введите.

Overview

Sub-menu: /tool traceroute

Traceroute displays the list of the routers that packet travels through to get to a remote host. The traceroute or tracepath tool is available on practically all Unix-like operating systems and tracert on Microsoft Windows operating systems.

Traceroute operation is based on TTL value and ICMP “Time Exceeded” message. Remember that TTL value in IP header is used to avoid routing loops. Each hop decrements TTL value by 1. If the TTL reaches zero, the packet is discarded and ICMP Time Exceeded message is sent back to the sender when this occurs.

Initially by traceroute, the TTL value is set to 1 when next router finds a packet with TTL = 1 it sets TTL value to zero, and responds with an ICMP «time exceeded» message to the source. This message lets the source know that the packet traverses that particular router as a hop. Next time TTL value is incremented by 1 and so on. Typically, each router in the path towards the destination decrements the TTL field by one unit TTL reaches zero.

Using this command you can see how packets travel through the network and where it may fail or slow down. Using this information you can determine the computer, router, switch or other network device that possibly causing network issues or failures.

Quick Example

[admin@MikroTik] > tool traceroute 10.255.255.1
     ADDRESS                                    STATUS
   1       10.0.1.17 2ms 1ms 1ms 
   2    10.255.255.1 5ms 1ms 1ms
[admin@MikroTik] >

Представим ситуацию: установлено и настроено нужное ПО для работы, которое взаимодействует с другими серверами в сети (любое web-приложение, использующее БД на удаленном сервере, резервное копирование по сети и др.). До какого-то момента все работает корректно и без задержек, но внезапно либо ПО начинает работать заметно медленнее, либо перестает работать полностью. Как понять на каком сервере возникла проблема? На каком этапе передачи трафика возникает задержка или ограничение? Каким образом провести диагностику сетевого подключения?

Установка traceroute

Утилита ping поможет понять доступен ли удаленный сервер, но в дальнейшей диагностике потребуются уже другие инструменты, одним из которых является traceroute. Эта утилита способна выполнить трассировку сетевых соединений. Данные traceroute показывают через какие узлы (маршрутизаторы) проходит пакет, сколько времени занимает обработка пакета на каждом узле.

Утилита часто уже предустановлена в ОС, и сразу доступна для использования. Если все же она отсутствует, то установить ее можно из стандартного репозитория дистрибутива с помощью менеджера пакетов:

• для deb-based дистрибутива:

sudo apt install traceroute

• для rpm-based дистрибутива:

sudo yum install traceroute

Как работает traceroute

Утилита отслеживает, на какие узлы попадает сетевой пакет в процессе его передачи на целевой хост. По умолчанию используется UDP протокол – формируется UDP датаграмма, которая упаковывается в IP пакет. В одном из заголовков этого пакета утилита устанавливает значение параметра TTL (Time To Live) равным 1. Этот параметр используется для ограничения количества переходов от одного маршрутизатора к другому, т.е. позволяет избежать бесконечной передачи пакета между маршрутизаторами (например, в случае некорректно настроенного протокола динамической маршрутизации, или при ошибках в статических маршрутах). Каждый маршрутизатор, получив пакет, уменьшает значение TTL на 1 перед отправкой далее в сеть. В ситуации, когда после очередного уменьшения TTL становится равным 0 пакет считается недоставленным и отбрасывается, при этом маршрутизатор отвечает отправителю сообщением об ошибке.

При TTL = 1 traceroute, получая ответ от первого маршрутизатора, определяет его IP адрес и время, затраченное на обработку пакета. После этого TTL увеличивается на единицу для определения следующего маршрутизатора, и так далее до момента попадания пакета на целевой хост. Утилита использует указанный ей IP-адрес, и порт 34434 по умолчанию. Целевой хост принимает пакет, и отправляет сообщение о недоступности порта 34434 (так как в большинстве случаев он не используется каким-либо сервисом и закрыт). В итоге отслеживается вся цепочка следования пакета, которая завершается ответом от целевого хоста.

Маршрутизатором является любое устройство, передающее пакет из одной подсети в другую — это может быть какой-либо сервер, а не специализированное сетевое устройство. Это особенно актуально для микросервисной архитектуры приложений, использующей технологии контейнеризации. Анализируя время, затраченное на переход от одного маршрутизатора к другому, можно определить на каком из них возникает задержка – возможно из-за нехватки ресурсов на одном из серверов, или из-за неисправности дисковой системы, и др. Если один из серверов недоступен, то пакет не дойдет до целевого хоста, и утилита определит на каком этапе передачи это происходит. Также, пакет не дойдет если действует фильтрация трафика, мешающая передачи пакета.

Запуск traceroute

Обязательным для утилиты является имя целевого хоста или IP адрес:

traceroute linux.org

Вывод команды:

Какие данные получены этой командой и отображены в выводе в виде таблицы:

• потребовалось 5 переходов (или хопов – hops), их число отображено в первом столбце;
• на каждом хопе определен IP адрес следующего маршрутизатора и его имя (при наличии);
• время (RTT – Round Trip Time), затраченное на отправку и получения запроса от маршрутизатора.

По умолчанию traceroute отправляет три UDP пакета, поэтому в выводе отображены три значения RTT. Для первой строки это 3.034 ms, 5.349 ms, 5.325 ms. Другим значением по умолчанию является количество хопов, которые может пройти пакет, т.е. TTL = 30. Произвольное значение, например 35, можно указать в строке запуска с опцией « -m 35 ».
На некоторых хопах может быть определено более одного маршрутизатора – это происходит из-за наличия нескольких маршрутов на этом этапе. Отправляя сразу три UDP пакета ответ может приходить от трех разных маршрутизаторов, и для каждого также указано RTT. Пример такого ответа на четвертом хопе: определены IP 172.71.180.2 и 172.71.100.2, через которые возможна доставка пакетов на целевой хост.

Необходимо обращать внимание на хопы имеющие большое значение RTT – это означает, что маршрутизатор долго обрабатывает пакет, и необходимо выяснить причину такой задержки.

Стоит отметить, что ответ может приходить отправителю альтернативным маршрутом, либо использования технологий балансировки нагрузки. Если на каком-то хопе имеется высокий RTT, то стоит запустить утилиту еще раз и проверить результат. Также, на одном из маршрутизаторов могут быть в действии фильтры пакетов, либо это может быть специализированный Firewall. В таком случае возможны ограничения для порта или UDP протокола, и в выводе traceroute будут отображены три звездочки (т.е. превышен таймаут получения ответа):

traceroute mongodb.org

Ресурс mongodb.com доступен, но UDP пакеты фильтруются.

Traceroute может использовать ICMP протокол вместо UDP – отправляется один запрос «Echo Request», в ответ также приходят ICMP сообщения, порт не используется. В остальном – схема работы не отличается. Опция « -I » в строке запуска для ICMP трассировки:

traceroute mongodb.org -I

Видно, что ответ получен от целевого хоста, хотя с 5 по 21 хопы ответы не приходят.

TCP протокол также может быть использован (опция « -T ») – в этом случае отправляются SYN запросы на 80 порт.

Полезные опции traceroute

• « -4 » и « -6 », указание протоколов IPv4 и IPv6 соответственно;
• « -i », указание сетевого интерфейса, например «-i ens0s5»;
• « -n », отключение определения доменного имени для IP маршрутизатора;
• « -p », указание произвольного порта (для UDP и TCP);
• « -m », максимальное количество переходов (хопов).

Трассировка в ОС Windows

Утилита tracert доступна в ОС Windows для трассировки сети аналогично traceroute в ОС Linux. Эта утилита использует только ICMP протокол, имеет меньшее количество опций, в остальном процесс не отличается от traceroute.

Заключение

Traceroute является удобным инструментом для диагностики сетевых подключений, помогающий определить на каком узле возникают задержки или ограничения для прохождения трафика. При этом, интерпретировать результаты его работы не всегда просто из-за правил фильтрации, систем перенаправления и балансировки трафика. Для диагностики распределенного приложения требуется четкое представление об используемой архитектуре. Комбинирование доступных опций также полезно для диагностики внешних ресурсов.

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»