Pull to refresh

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

Reading time4 min
Views165K
  • Почему в трейсроуте после узла 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, файрволы на пути трассировки могут иметь неодинаковые настройки фильтрации для разных протоколов.
  • При интерпретации результатов трассировки требуется опыт и сообразительность. Бывает, что важные выводы можно сделать лишь путем догадки, опираясь на косвенные данные, а иные — и вовсе не однозначно, а лишь с точностью до «скорее всего».

Итого


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

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

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

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

Articles

Change theme settings