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

    Итого


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

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

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

    Прочтите презентацию Ричарда. С осторожностью пользуйтесь трейсроутом, как основным инструментом траблшутинга: ошибиться в интерпретации очень легко, информации часто недостаточно для однозначных выводов. Всегда сопоставляйте показания трейсроута с другими доступными данными, по возможности пользуйтесь им лишь в качестве дополнительной или черновой информации.
    Поделиться публикацией
    Комментарии 42
      +2
      в линуксе кроме traceroute есть ещё утилита tracepath. В чём отличие? (кроме того, что traceroute требует права рута, а tracepath — нет)
        0
        traceroute не требует рутовых прав
          +2
          Когда как :)

          user@host:~$ traceroute www.ru -I
          The specified type of tracerouting is allowed for superuser only
            0
            Только для ICMP, нужен (по моему опыту) крайне редко.
          +1
          Судя по описанию http://www.opennet.ru/man.shtml?topic=tracepath&category=8&russian=0, её отличие в том что она не требует привилегий суперпользователя и не имеет расширенных настроек. И всё.
            +2
            где вы такой traceroute нашли? Зайдите на любой обычный хостинг и попробуйте сделать traceroute если админ не слишком умный, то вы сделаете это без особых усилий.

              +1
              man tracepath:

              tracepath, tracepath6 — traces path to a network host discovering MTU along this path

              Курсив мой. tracepath по умолчанию пытается определить mtu на каждом из линков пути. Трейсроут это тоже может, но со специальным ключом.
                +7
                есть куда более информативный mtr
                  +3
                  беими руками и ногами за mtr — статистика всегда решает…
                    +1
                    Самый большой плюс — совмещение трэйса и пинга.

                    Заодно, если меняется один из узлов, то это отображается.
                      +4
                      В Windows, кстати, есть аналог mtr — штатная утилита pathping, но она сбивается, если какой-то узел по маршруту на icmp не отвечает (упомянутые звездочки). Так что winmtr для этих целей намного лучше.
                    +1
                    У traceroute много всяких различных опций, можно трассировать и UDP и TCP и ICMP и много чего еще.
                    А tracepath простой, но умеет показывать когда трафик предположительно идет не симметрично «asymm».
                    +29
                    Если кратко: вы не умеете читать вывод трейсроута. Даже не пытайтесь.
                      +6
                      Только у меня ощущение что прочел много букв а в голове осталась только одны мысль?
                        0
                        В целом не без этого. Точнее, если лень всерьез разбираться, кто таки оно работает, то как минимум не нежно никому рассказывать, о том, что вы там прочли :)
                          +2
                          Ну вы хотя бы объяснили про звёздочки =)
                            +4
                            :) Звездочки в N-ной строчке — это отсутствие ответа на пакеты с TTL=n. По какой-то причине вам не хотят отвечать. Ничего криминального в этом нет. И в большинстве случаев это не имеет никакого отношения к работоспособности сервиса, который вы трейсите.

                            Делаете вы трейс на какой-нибудь www.ru. Перед веб-сервером наверняка стоит файрвол, который блокирет все, кроме tcp/80, tcp/443 и icmp echo-request. И правильно делает, что блокирует. Соответственно, UDP-трейс через такой файрвол не пролезет — вы увидите звездочки. При этом сам файрвол, если вы его потрейсите, вполне вероятно, вам ответит, а если сквозь него — на сервер, который за ним — может и не ответить (а может и ответить, но дальше не пустить — смотря как настроено, и какой файрвол). Если не ответит, то при трассировке сервера последним хопом в трейсе будет маршрутизатор перед файрволом.

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

                            А уж если все-таки хочется знать ответы, то доклад Ричарда — это 54 слайда конскими буквами (по 10 строчек на слайд) с картинками и слайдами-заголовками.
                              0
                              А я уж было подумал, что неверно истолковываю вывод трейсроута, связанный со звёздочками.
                                0
                                В презентации описаны еще случаи, когда возможны звездочки.
                        +9
                        а я то ожидал в статье какой-то практической составляющей и надеялся подчерпнуть для себя что-то новое. Ладно, сольём доклад — почитаем на досуге.
                          +18
                          А где же ответы на вопросы в начале статьи?
                            +12
                            не знаю про ответы, но я теперь боюсь использовать traceroute, вдруг что-то не правильно пойму и все — конец! =)
                              0
                              В докладе Ричарда.

                              А я не про ответы на вопросы, а про необходимость эти вопросы задавать. Не побоюсь этого слова, большинству пользователей не надо. Даже большинству админов не надо. Просто вот не надо и все — толку больше будет.
                              +2
                              Это конечно оффтоп, и выступлю в роли Кепа, но ИМХО простому юзеру, да и в 99% случаев админу mtr удобнее ;) единственно на линухе его часто ставить надо отдельно.
                              Но зато, иногда, с его помощью можно избежать некоторых проблем трейсроута.
                                0
                                Вот как раз удивительное дело — только что обнаружил, что в свежей кубунте по умолчанию есть mtr, но нет traceroute (!)
                                +1
                                > Трейсроут трейсроуту рознь. Стандартные утилиты tracert в Windows и traceroute
                                > в Линукс реализованы по-разному и могут давать разные результаты.
                                > Windows посылает ICMP, а Linux — UDP

                                В Windows утилита tracert действительно использует только ICMP.
                                Но traceroute в *nix-системах (Linux, BSD, etc.) может использовать, как UDP, так и ICMP.
                                По умолчанию UDP, с ключиком -I будет использовать ICMP.
                                  0
                                  TRACEROUTE(8)

                                  traceroute — print the route packets trace to network host
                                  tracert is equivalent to traceroute -I
                                  tcptraceroute is equivalent to traceroute -T
                                  +3
                                  Ни о чем… Только вопросов позадавали без ответов. Хотели дать ссылку на презентацию? Тогда и надо было ссылку делать. А в постах пишут ответы, а не вопросы.
                                    +1
                                    :) См. мой ответ юзеру lostmsu.

                                    habrahabr.ru/blogs/network_technologies/129627/#comment_4293976
                                      0
                                      Ссылку на эту статью мне только что скинул дежурный администратор Rascom. Смысл этого его действия и смысл этой статьи не в разжевывании ответов на поставленные вопросы. Правильно поставленные вопросы лучше ответов, так как ответы на них можно искать лично и в разных источниках, главное знать формулировку вопроса. С этим иногда больше проблем, чем с поиском ответов.
                                      +2
                                      Как-то вообще не вкусно — где же обещанное разжевывание трэйсроута?
                                        +1
                                        Эээ… где и кем обещанное? :)
                                          0
                                          Косвенно ;)
                                            +1
                                            Видно надо было про заколебавшихся отвечать на эти вопросы под кат не вносить :)
                                        +1
                                        mtr действительно куда удобнее.
                                        хотя бы тем, что не подвисает на неопределенное время в попытках отлукапить ptr полученного адреса, а продолжает трассировку. любителей делать traceroute -n (tracert -d) во внешние сети я никогда не понимал.
                                          0
                                          Честно говоря, я никогда не понимал любителей делать эту трассировку и без ключа -n/-d. Ну то есть понимал, конечно: круто почувствовать себя причастным к тайному знанию внутренней структуры интернета. Но если бы это простым любопытством и заканчивалось, то оно бы и ничего. Ну или стимулировало к дальнейшему его удовлетворению путем чтения книг. А то ведь увидел звездочки или задержку в 100 мс — и сразу какраул кричать :)
                                          +1
                                          Никакой конкретики. Одна вода.
                                            +3
                                            Трафик в интернете почти всегда идет разными путями в направлениях от клиента к серверу и от сервера к клиенту. Трейсроут же всегда показывает суммарную задержку в обе стороны, а трассировку — только по одному направлению.

                                            Вот это действительно очень сложно для понимания неподготовленным то и дело можно слышать «да у вас там голден тупит», хотя на деле затык на обратке через рт )
                                              +1
                                              В докладе два раза повторяется страница 42, странное совпадение.
                                                0
                                                Какое совпадение? С чем совпадение? В каком докладе 42 страница два раза? В том, что по ссылке? Странно, посмотрел — не нашел.
                                                –1
                                                Как то пост не о чём. Для приличия хоть бы pdf перевод сделали.
                                                  +1
                                                  Если в кратце что не плохо знать

                                                  1) Routing on the Internet has no guarantee of symmetry.
                                                  Traceroute shows you only the forward path.
                                                  The reverse path is completely invisible to traceroute.

                                                  2) Все реализации traceroute полагаються на пакеты ICMP (тип 11), посылаемых отправителю.
                                                  а) Windows OS
                                                  tracert.exe
                                                  отправитель: отсылает 3 пакета ICMP-тип8 с TTL=1
                                                  --ответ от-- промежут. устр.: ICMP-тип11 с TTL=1
                                                  --ответ от-- цели: ICMP-тип0

                                                  PathPing.exe = combines ping and traceroute functionality.

                                                  б) FreeBSD, Linux & Cisco IOS
                                                  отправитель: отсылает (со случайные портов) UDP датаграммы на порты цели >=33434 с TTL=1 (следующий пакет — порт назначения увеличивается)
                                                  --ответ от-- промежут. устр.: ICMP-тип11 с TTL=1
                                                  --ответ от-- цели: ICMP-тип3 код 3 («destination unreachable,» «port unreachable»)

                                                  3) TCP is a poor choice for general use (frequently filtered), typically only seen as a method to work around specific firewalls.

                                                  и это есть гуд
                                                  C:\>tracert -w 100 www.microsoft.com
                                                  12 146 ms 126 ms 126 ms ge-0-0-0-0.ash-64cb-1a.ntwk.msn.net [207.46.43.2]
                                                  13 189 ms * 189 ms ge-0-1-0-0.co2-64c-1b.ntwk.msn.net [207.46.43.179]
                                                  14 191 ms 190 ms * xe-0-0-0-0.co2-96c-2b.ntwk.msn.net [207.46.43.69]
                                                  15 191 ms 191 ms * 207.46.40.242
                                                  16 * * * Request timed out.
                                                  17 * * * Request timed out.
                                                  18 * * * Request timed out.
                                                  19 * * * Request timed out.
                                                  20 * ^C

                                                  C:\>tracetcp.exe www.microsoft.com

                                                  11 120 ms 120 ms 120 ms 207.46.43.44 [ge-3-0-0-0.nyc-64cb-1a.ntwk.msn.net]
                                                  12 128 ms 127 ms 127 ms 207.46.43.2 [ge-0-0-0-0.ash-64cb-1a.ntwk.msn.net]
                                                  13 190 ms 190 ms 189 ms 207.46.43.179 [ge-0-1-0-0.co2-64c-1b.ntwk.msn.net]
                                                  14 192 ms 191 ms 191 ms 207.46.43.69 [xe-0-0-0-0.co2-96c-2b.ntwk.msn.net]
                                                  15 190 ms 190 ms 191 ms 207.46.40.242
                                                  16 * * * Request timed out.
                                                  17 Destination Reached in 192 ms. Connection established to 65.55.12.249

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

                                                  Самое читаемое