Какие адреса мы видим в traceroute

    Привет. Это короткая заметка про то, какие именно IP мы видим в любимом tracert/traceroute, и как это зависит от лейбла на коробках в аппаратных вашего ISP и его апстримов.

    Думаю, все знают, что у маршрутизатора, как правило, множество IP-адресов (ну или хотя бы точно больше, чем 1). В условиях такого многообразия перед маршрутизатором ставится нелегкий выбор: какой именно из его IP-адресов необходимо выбрать в качестве источника сообщения ICMP TTL Exceeded, которое и является основой для вывода трассировки?

    Если вы никогда ранее не задумывались над данным вопросом, то вот некоторые варианты, которые могут прийти в голову в первую очередь:

    1. IP-адрес интерфейса, который являлся входящим для оригинального пакета.
    2. IP-адрес интерфейса, который должен был бы являться исходящим для оригинального пакета.
    3. IP-адрес интерфейса, который будет являться исходящим для ICMP-сообщения.
    4. IP-адрес лупбэка.

    Если вы все же задумывались об этом ранее, то не спешите давать однозначный ответ :)

    Для ответа на вопрос из названия публикации я собрал вот такую лабу в GNS3:



    Некоторые пояснения к топологии:

    1. Трассировка будет производиться от PC1 к PC2.
    2. На каждом маршрутизаторе есть лупбэк вида X.X.X.X
    3. На всех роутерах и всех интерфейсах запущен OSPF Area 0.
    4. OSPF Interface Cost распределены таким образом, что трафик от любого роутера до 60.0.0.0/24 (сеть PC2) пойдет «вертикально», т.е. через цепочку оставшихся роутеров. И наоборот, трафик до 10.0.0.0/24 (сеть PC1) от любого роутера кроме Cisco1 пойдет через SW1 (что соответствует сети 123.0.0.0/24). Таким образом мы добиваемся ситуации, при которой входящий интерфейс оригинального пакета и исходящий интерфейс ICMP-сообщения не совпадают.

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

    Ответ: Для OSPF это действительно не самая типичная ситуация, он использовался исключительно для упрощения конфигурации. В реальности за асимметрию путей вашего трафика в основном ответственен BGP.

    Запускаем трассировку




    Как вы можете видеть, Cisco и Juniper ответили с IP входящего интерфейса, тогда как Debian Linux и Mikrotik (имеющий тот же Linux в корнях своей операционки) ответили с IP интерфейса, который являлся исходящим для ICMP-пакета (123.0.0.X).

    Record Route для сравнения:



    Заключение


    Поведение Linux и Mikrotik объясняется пунктом из RFC 1812. Этот пункт указывает, что source-адресом ICMP-сообщения должен являться адрес интерфейса, через который должен быть передан данный ICMP-пакет.

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

    Похожие публикации

    Комментарии 11

      +5
      Просто для справки всем остальным, можно использовать ключ -A в traceroute, тогда он покажет номер AS.

      Еще можно использовать mylg — https://github.com/mehrdadrad/mylg

      image
        0
        Ещё, при использовании VRF L3VPN и софта ниже 15 версии на Juniper, он имеет свойство отвечать с интерфейса, первее всего созданного в этом VRF. Говорят, что в JunOS 15 и старше, этот баг исправлен, но у нас до сих пор софт старый, проверить не можем.
          +1
          Если я отвечу «с какого попало», насколько я буду неправ в среднемедианной выборке по всем сетевым устройствам?

          Интуиция мне говорит, что я буду ближе к истине, чем любой из детерминированных ответов.
            0
            У Cisco ещё интересное поведение когда на интерфейсе более одного ip.
              +1
              А еще веселее бывает, когда на интерфейсе висит несколько IP. Циска (по-крайней мере на некоторых софтах) в трассировке отвечает с primary адреса. Соответственно, если у клиента IP из secondary подсети, то первым хопом в трассировке будет стоять не основной шлюз, а другой IP.
              Или MPLS/BGP L3 VPN. Там вообще ответ будет приходить от egress интерфейса. Что, в принципе, логично, так как IP ingress интерфейса не несет смысла в контексте самого VPN, но многих смущает. Это уже не говоря о веселье с пропагацией TTL.
              А уж Микротик можно всего парой строчек заставить выдавать такие коленца, что вообще швах.
                0
                Что покажет Windows tracert? Там, как помню, другой механизм.
                  0
                  Покажет абсолютно то же самое. Транзитным роутерам все равно, истек TTL у ICMP-пакета или у UDP :)
                  0
                  Хммм… Познавательно!!! Буду иметь ввиду!!!
                    0

                    Несмотря на rfc, поведение cisco мне кажется вполне логичными, отвечать с "ближайшего" интерфейса. Тут и соображения безопасности играют роль. Нечего пакету гулять по просторам таблицы маршрутизации.

                      +1
                      Чисто теоретически, какие-то сегменты сети могут пропускать пакеты только в одном направлении (тот же спутниковый приёмник, к примеру).

                      Поэтому мне кажется логичным отвечать не в тот интерфейс, откуда пришёл пакет, а в тот интерфейс, через который правилами маршрутизации настроена доставка получателю.
                      0
                      Cisco — это ни о чём, какая версия софта и на каком железе? но «как попало» — да.

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

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