Traceroute что значит x

Traceroute: про умение читать вывод

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

По поводу взаимоотношений с трейсроутом Ричард нашевсе Стинберген сделал на конференции NANOG-47 (2009) доклад, тезисы которого я и рекомендую к изучению всем заинтересованным лицам. A Practical Guide to (Correctly) Troubleshooting with Traceroute (PDF, 222 КБ) (на английском, разумеется, языке).

Не стану пересказывать тут подробности (желающие да прочтут), остановлюсь лишь на своде аргументов и выводах, которые хорошо бы иметь в виду, прежде чем звать на помощь с криком «у меня трейс показывает, что…»

Все ниже (и выше) излагаемое — моя личная точка зрения. Топик написан под влиянием указанной презентации, но не является ни ее пересказом, ни, упаси господь, переводом. Возможно даже, вы сможете обнаружить в ней разночтения с данным топиком. Уж как минимум не стоит приписывать Ричарду тех или иных высказываний, прочтя их у меня, но не сверившись с его докладом.

Некоторые факты (без углубления в детали)

Некоторые наиболее важные выводы (с моим творческим осмыслением)

Итого

Если вы клиент

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

Если вы не видите проблем с сервисом (все работает), но в выводе трейсроута вам что-то не нравится — подумайте хорошенько, прежде чем подымать тревогу. Крайне вероятно, что вы просто неверно интерпретируете вывод. Очень нечасто по одному трейсроуту можно судить о наличии проблемы. А если проблема действительно есть, обычно ее проще продемонстрировать без трейсроута.

Если вы исполнитель

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

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

Источник

Сайт ARNY.RU

Troubleshooting часть 1 — углубляемся в ping и traceroute, разбираем малоизвестные факты об этих популярных инструментах траблшутинга.

Всем знакомые ping и traceroute. Все их используют и не особо обращают внимание. А что там знать? Ведь команды эти крайне простые. Всё ли так просто на самом деле? Проверь себя. Рассказ как всегда в контексте устройств CISCO.

Traceroute

Сначала traceroute, здесь поинтереснее. Самое первое тут: traceroute может использовать разные протоколы передачи данных и конкретно в CISCO это не ICMP. Да, вот в CISCO так. Здесь UDP, поэтому в настройках расширенного traceroute есть пункт выбора порта. Порт по умолчанию 33434, его можно поменять.

Тем не менее traceroute всё равно задействует ICMP в своей работе. И механизм этой работы такой: пакеты с UDP начинкой отправляются с различным TTL (от 1 до 30). Для первого пакета TTL равен единице, для второго двум и так далее.

На каждом хопе TTL уменьшается на 1 и когда он обнуляется, то устройство где это произошло, отправляет ICMP собщение отправителю о данном событии (ICMP Time Exceeded Message, TEM). Из этого сообщения извлекается информация (IP адрес отправителя) и выводится на экран. Каждый следующий пакет уходит на один хоп дальше. Когда наконец пакет достигает хоста назначения, то оказывается что нет приложения прослушивающего UDP порт, указанный в пакете, и хост отправляет об этом сообщение (ICMP Port Unreachable Message). Всё, трассировка завершена.

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

Теперь подробнее, обращаю внимание что для ping и traceroute есть одинаковые инфомационные сообщения в выводе, только с разным значением. Разберём и вот эти непонятки проясним.

Расшифровка вывода traceroute

Запомним первые два: «крышечка» U недоступен порт, H недоступен хост.

Параметры команды traceroute

Тут зависит от модели устройства и IOS, может быть и вот так:

Описание основных параметров:

Пример

Расширенная трассировка, адрес 192.168.3.1 находится в двух хопах от нашего роутера R1:

Какие здесь моменты? В пункте Source address or interface имя интерфейса нельзя сокращать. Команда traceroute вываливает все свои параметры, не спрашивая нас (для пинга по-другому). Loose, Strict, Record, Timestamp, Verbose рассмотрим в разделе про пинг. Для второй пробы к 10.20.3.3 превышено время ожидания ответа (*).

Debug команды traceroute

Включим дебаг и будем ещё смотреть с помощью Wireshark:

Посмотрим пакет в Wireshark, очистим вывод с помощью фильтра:

Что мы здесь видим? Было отправлено 6 пакетов, это имено пакеты UDP, в IP заголовке номер протокола 17. Пакеты высылались на порт 33434 для первого пакета и +1 для каждого следующего. Поэтому для шестого 33439. В ответ получено 5 ICMP ответов, 3 Time exceeded, 2 Port unreachable. Все эти ответы видны в дебаге роутера.

Служит для проверки доступности узла сети. С успешным пингом всё понятно — узел доступен. С неуспешным сложнее, как правило этого недостаточно чтобы сделать какой-то вывод. Требуются дополнительные инструменты и нужно выяснить что там с устройством случилось. Или ничего не случилось. Допустим, узел находится где-то в интернете и администратор закрыл ICMP запросы из интернета. Устройство нормально работает, при этом пропинговать его невозможно.

Внутри локальной сети попроще. Если известно что узел должен пинговаться и вот он не пигуется, значит что-то не в порядке. Опять же нужны дополнительные инструменты. Топ 3 причин неудачного пинга: нет элетричества или сбой ИБП, «добрый самаритянин» выдернул провода (сетевые или электрические) или повредили кабель при ремонтных работах (экскаватор перебил оптику), устройство ушло в ребут (в циклический ребут).

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

Расшифровка вывода ping

Для ping и tracerote U в выводе имеет разное значение, для пинга U то же самое что H для traceroute. Не знаю как сейчас, но раньше CISCO просто обожала на своих экзаменах бомбить вопросами на знание подобных мелочей.

Пример

Пусть роутер R1 не знает о сети 192.168.10.0/24, то есть её нет в его таблице маршрутизации. И нет маршрута по умолчанию, значит R1 не знает куда отсылать пакеты для этой сети. Тут всё ясно, точки и звёздочки:

Теперь добавим на R1 маршрут по умолчанию, указывающий на IP адрес роутера R2 (адрес следующего перехода). Роутер R2 также не знает о сети 192.168.10.0/24. R1 будет отправлять пакеты на R2 и ждать ответа от R2:

Теперь поподробнее что же такое unreachable. Если поднимем на R2 ещё дополнительный интерфейс и назначим ему 192.168.10.2/24, то интерфейс UP и таблице маршрутизации появится связанный маршрут:

Снова запустим пинг и traceroute к 192.168.10.1 с R1. Снова будут точки и звёздочки, таймаут. Другими словами, unreachable — это когда роутер (его адрес будет в строчке вывода traceroute) по пути следования пакета (но не локальный роутер) не знает куда дальше пересылать пакет.

Параметры команды ping

Опять же набор параметров может отличаться, основные параметры:

Пример

Если мы принудительно не включим расширенные команды, то они и недоступны, в отличие от traceroute. Sweep range of sizes будет увеличивать размер пакета от начального значения до конечного с указанным шагом.

Прервал выполение команды (для этого есть удобная комбинация клавиш Ctrl-Shift-6). Можно использовать Sweep range для проверки MTU (при установленном бите DF в расширенных командах). Ну и собственно сами расширенные команды:

Тут подробнее про Loose, Strict, Record, Timestamp, Verbose.

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

Debug команды ping

Для сокращения вывода использовал один пакет. Мы один запрос отправили, один ответ получили. Смотрим Wireshark:

Ходовой вопрос на собеседованиях: для пинга какой порт используется? Никакой. Почему? Чтобы был порт, должен быть заголовок транспортного уровня (TCP/UDP). Для ICMP такого заголовка просто нет в пакете, ICMP цепляется непосредственно к IP заголовку. При этом в IP заголовке номер протокола 1. Самые ходовые протоколы, на собеседовании бывает спрашивают:

Список номеров всех протоколов тут. Ну вот, надеюсь что-то полезное рассказал. Не стал специально переводить описание к параметрам, так как лучше прочитать в оригинале, чем мой неточный перевод. Кому сложно в оригинале, переводчик в помощь. А вообще пора учить английский.

Источник

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

Применение данных утил позволяет проследить маршрут до удаленного хоста, определить время круговой задержки (RTT-round-trip delay time), IP-адрес и в некоторых случаях доменное имя промежуточного маршрутизатора. В основе их работы лежат ICMP-сообщения об ошибках.

Как работает Tracert.

Значение времени жизни (TTL) первого отправляемого пакета устанавливается равным 1. Когда протокол IP первого маршрутизатора принимает этот пакет, то он в соответствии со своим алгоритмом уменьшает TTL на единицу и получает 0. Маршрутизатор отбрасывает пакет с нулевым временем жизни и возвращает узлу-источнику ICMP-сообщение об ошибке истечения времени дейтаграммы (ICMP-сообщение тип 11 код 0). Это сообщение содержит имя маршрутизатора и его IP-адрес. Когда это ICMP-сообщение прибывает к отправителю, тот по значению таймера узнает время оборота пакета(RTT), а также (из ICMP-сообщения) имя и IP-адрес промежуточного маршрутизатора. Затем посылается следующий IP-пакет, но теперь со значением TTL равным 2. Этот пакет уже доходит до второго маршрутизатора, но опять там «умирает» о чем аналогичным, же образом сообщается узлу отправителю. И так до тех пор, пока не достигнет конечного узла. На основании данных ответов строится трассировка. Например:

Из данной трассы мы видим, что хост www.rt.ru доступен с числом прыжков(хопов) — 8, его ip 109.207.14.4, и время круговой задержки до данного ресурса составляет 19ms.

Как работает Traсeroute.

Принцип идентичный, за одним исключением. Утила по умолчанию, посылает в сторону заданного хоста UDP-датаграммы на какой-то произвольный порт, обычно — на «высокий», скорее всего не занятый другим сервисом (например 12500, 30678) или на зарезервированный (например 0), в свежих версиях порт по умолчанию — 33434. Сначала посылается серия из 3-х таких пакетов с TTL=1, по приходу ответов замеряется время прохождения и определяется доменное имя транзитного узла. Затем, как сказано выше, посылаются очередные серии пакетов с TTL=2 и т.д. В конце мы получаем от конечного хоста отклик «Порт недоступен» (PORT_UNREACHABLE), что означает завершение трассировки.

Пример трассировки до того же ресурса:

Заключение.

Следует отметить, что звездочки могут возникать и при трассировке ICMP-пакетами, это также не значит, что существует проблема. Все зависит от того, как настроил оборудование администратор. Это его железо и настраивается оно с его потребностями. Данное явление вполне нормально. Также не следует паниковать, если конечный хост не пингуется. Вполне возможно, что ресурс просто от них закрылся.

Источник

Как запустить Traceroute в Linux

Traceroute — это инструмент в Linux, позволяющий исследовать маршруты сетевых пакетов. Это может помочь вам определить ограничивающий фактор перемещения сетевых пакетов. Traceroute также полезен для устранения проблем с медленными сетевыми подключениями. В этом руководстве показано, как запустить traceroute в Linux.

О трассировке

Traceroute отправляет пакеты данных на целевой компьютер, сервер или веб-сайт и записывает любые промежуточные шаги, через которые проходят пакеты. Результатом команды traceroute будут IP-адреса и доменные имена, через которые проходят пакеты. Эти записи также показывают, сколько времени требуется, чтобы пакеты достигли каждого пункта назначения. Это может объяснить, почему некоторые веб-сайты загружаются дольше, чем другие, поскольку количество переходов трафика может варьироваться.

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

Обратите внимание, что при использовании traceroute некоторые устройства могут плохо взаимодействовать. Это может быть связано с ошибками маршрутизаторов, ограничивающими скорость сообщениями ICMP интернет-провайдерами, устройствами, не настроенными для отправки пакетов ICMP (для предотвращения распределенных DoS-атак) и т.д. Некоторые сети также настроены на блокировку запросов трассировки.

Установка traceroute

Traceroute — мощный инструмент, доступный для всех дистрибутивов Linux. Ниже приводится краткий список команд для установки traceroute в различных дистрибутивах.

Для Debian/Ubuntu и производных:

Для Fedora и производных:

Для openSUSE, SUSE Linux и производных:

Для Arch Linux и производных:

Использование traceroute

В следующих разделах показано, как использовать traceroute в вашей системе Linux.

Основное использование

Основной метод использования traceroute довольно прост. Все, что требуется traceroute, — это пункт назначения для выполнения зондирования. Назначением может быть домен или IP-адрес.

Если сеть настроена на блокировку сигнала traceroute, то этот зонд будет отмечен звездочками.

IPv4 или IPv6

По умолчанию traceroute будет использовать Интернет-протокол по умолчанию, на который настроена ваша система. Чтобы вручную установить версию IP, выполните описанную ниже процедуру.

Тестирование портов

Скрытие имен устройств

Предел тайм-аута Traceroute

Методы исследования

Установка максимального количества прыжков

По умолчанию traceroute отслеживает 30 переходов. Traceroute предлагает возможность вручную установить количество отслеживаемых переходов.

Указание интерфейса

Определение количества запросов для прыжка

Маршрутизация пакетов через шлюз

Страница справки Traceroute

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

Чтобы получить более полное и подробное руководство по всем доступным параметрам traceroute, посетите страницу руководства с помощью следующей команды:

Заключение

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

А ранее мы писали об использовании аналогичной команды tracert в Windows.

Источник

Команда TRACERT: что это, отличие от PING, как пользоваться?

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

Утилита командной строки Traceroute – это инструмент, который используется для определения точного маршрута, по которому пакет данных проходит в сети Интернет от отправителя до места назначения.

При помощи команды tracert (Windows) или traceroute (Linux и Mac OS) вы легко и быстро можете определить где находится проблема, узкое место в передаче данных, задержка соединения с сервером. Также вы можете использовать утилиту, если вам просто интересно узнать какой путь проделывает пакет данных до места назначения.

Чем Tracert отличается от Ping?

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

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

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

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

Для примера проследим путь от моего ПК до сайта Google. В командной строке ввожу:

Вместо доменного имени вы можете также ввести ip-адрес удаленного сервера.

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

Также маршрутизатор укажет время, измеренное в милисекундах, за которое три пакета данных прошли к нему и от него. Рассмотрим полученные результаты.

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

Как видим, на первом этапе передача пакетов произошла менее чем за 1 ms. Первой точкой перехода был мой домашний модем-роутер (маршрутизатор). Этот маршрут самый короткий и быстрый, поскольку он проходит в пределах моей локальной сети. Но как только данные попадают в Интернет (второй прыжок), время приема-передачи значительно увеличивается. И чем дальше пакеты данных должны пройти к каждому маршрутизатору, тем больше времени будет затрачено на это.

Достижение конечного пункта назначения будет самым длительным этапом. Его значение будет соответствовать результату, полученному при помощи команды Ping. Потому что, как вы помните, ping отображает только время достижения конечного пункта на пути следования пакетов данных.

Последний столбец отчета traceroute сообщает IP-адрес или доменное имя каждого встреченного маршрутизатора.

Как установить проблему при помощи трассировки?

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

Проблема есть, но на каком именно этапе прохождения пакетов данных она возникает команда Ping не показывает.

Утилита Tracert поможет определить корень проблемы. Проанализируем отчет трассировки:

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

Что означают звездочки в отчете?

Иногда в отчете трассировки вы можете заметить звездочки, исходящие от маршрутизатора.

Это может означать как наличие проблемы с данным маршрутизатором, так и то, что он работает нормально, но не был настроен для возврата ответов tracert. Узел принял и передал пакеты в штатном режиме, но просто не сообщил затраченное на это время.

Что такое TTL?

После запуска tracert в окне командной строки можно прочесть такую фразу: «с максимальным числом прыжков 30» (на русском или английском).

Количество таких прыжков (hops) определяет параметр TTL (Time To Live), или время жизни. Он задает то, как долго переданные пакеты данных могут жить прежде чем будут отброшены. По умолчанию задаётся 30 прыжков. Если пакеты не достигают цели через 30 переходов, они автоматически отбрасываются.

tracert –h 4 google.com

Вышеуказанная запись означает, что когда данные достигают четвертого прыжка (узла), они отбрасываются и не передаются далее.

Для чего вообще нужен TTL? TTL способен предотвратить бесконечное перемещение пакета данных по сети Интернет в попытках найти пункт назначения. Такое может случиться, если некоторые маршрутизаторы в Интернет были неправильно настроены, и данные могут попасть в бесконечный цикл между этими маршрутизаторами без перспективы «прорваться» на следующий узел на своем пути до цели.

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

Источник