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

Почему в трейсроуте после узла X идут звездочки?
Сервис не работает, а трейсроут обрывается на узле X — значит проблема в узле X?
Почему одинаковые трейсроуты с Windows и Unix показывают разные результаты?
Почему трейсроут показывает большие задержки на определенном узле?
Почему трейсроут показывает «серые» адреса при трассировке через интернет?
Почему маршрутизатор отвечает на трейсроут не тем адресом, каким я хочу?
Почему трейсроут показывает какие-то «не такие» доменные имена?
Почему вообще вывод трейсроута отличается от интуитивно ожидаемого чаще, чем хотелось бы?

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

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

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

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

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

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

Задержка прохождения пакета по сети складывается из нескольких факторов: сериализация, буферизация, распространение. Каждый из факторов сложнее, чем вы о нем думаете.
Задержка, которую вам показывает трейсроут, — еще более комплексная величина: маршрутизаторы обрабатывают пакеты, адресованные самим себе, абсолютно иначе, чем транзитные пакеты. Данное обстоятельство приводит к специфической природе значений задержек, которые нам показывает трейсроут. Из этого не следует, что на них нельзя ориентироваться, но нужно уметь их читать.
Трафик в интернете почти всегда идет разными путями в направлениях от клиента к серверу и от сервера к клиенту. Трейсроут же всегда показывает суммарную задержку в обе стороны, а трассировку — только по одному направлению.
Указание трейсроуту адреса источника на устройстве с несколькими интерфейсами (маршрутизаторе) не влияет на выбор интерфейса, с которого будут отправлены запросы. А влияет — на выбор обратного пути, по которому передаются ответы. Их трассировка не видна в выводе, но таким образом можно измерять разницу задержки для параллельных обратных маршрутов.
Использование L3-балансировки где-то на интернет-магистралях скорее всего заставит разные пакеты в рамках одной трассировки идти разными путями. Такое поведение приводит к сложноинтерпретируемому выводу, грамотно прочесть который может далеко не каждый.
Современные маршрутизаторы при ответе на трейсроут не соблюдают требования пункта 4.3.2.4 RFC1812, обязывающего устанавливать IP-адрес источника ICMP-ответов равным адресу исходящего интерфейса. Вместо этого они устанавливают его равным адресу интерфейса, на который был получен трейсроут-запрос (пакет с TTL=1). Впрочем, если б было наоборот, читать вывод трейсроута было бы куда тяжелее.
Наличие MPLS-коммутации внутри магистральных сетей (нынче это так у любого уважающего себя крупного провайдера) приводит к контруинтуитивному пути передачи ответов на трейсроут и еще менее очевидному способу вычисления задержек.

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

Трейсроут — не такая простая штука, как кажется; ею нужно уметь пользоваться. А для этого надо понимать, как она работает.
Большинство админов и инженеров служб эксплуатации, не говоря уже о простых пользователях, не понимают и не умеют. Такое положение дел очень часто приводит к ложным тревогам, неправильной диагностике и т. п.
Трейсроут трейсроуту рознь. Стандартные утилиты tracert в Windows и traceroute в Линукс реализованы по-разному и могут давать разные результаты. Windows посылает ICMP, а Linux — UDP, файрволы на пути трассировки могут иметь неодинаковые настройки фильтрации для разных протоколов.
При интерпретации результатов трассировки требуется опыт и сообразительность. Бывает, что важные выводы можно сделать лишь путем догадки, опираясь на косвенные данные, а иные — и вовсе не однозначно, а лишь с точностью до «скорее всего».

Итого

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

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

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

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

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

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