Привет Хабр. Это транскрипция выступления облачного архитектора Qrator Labs, Александра Зубкова, про циклы маршрутизации. Русская версия данного доклада была впервые представлена на конференции ENOG 18 в июне этого года.

Добрый день! Меня зовут Александр Зубков, я работаю в Qrator Labs и сегодня я хочу поговорить о циклах маршрутизации.

Собственно, цикл маршрутизации это такая ситуация в Интернете, когда пакет, потенциально, бесконечно маршрутизируется по кругу. “Потенциально” потому что у нас есть защита от этого в IP-протоколе в форме TTL-поля, но даже при условии этого, если пакет с большим TTL’ем попадает в цикл - он может находится в нём достаточно долго, потому что максимальный TTL равен 255. И также возможны ситуации когда в пути TTL меняется и это может привести к реальным бесконечным циклам. Чтобы обнаружить цикл маршрутизации мы можем воспользоваться вот таким механизмом и если мы получаем на какой-то пакет ICMP ошибку о том что TTL иссяк, то это скорее всего одна из двух ситуаций: либо это длинный путь для которого нам не хватило TTL, либо это цикл маршрутизации в который попал пакет.

В Linux’е значение TTL по умолчанию равно 64, мы можем считать что этого хватает для Интернета и если у нас для довольно большого TTL вернулась ошибка, то мы можем считать что это почти гарантированно цикл, только если кто-то нас не обманывает специально.

Помимо того что таким образом мы можем обнаружить цикл, мы можем еще захотеть посмотреть на него - для этого можно воспользоваться утилитами вроде traceroute и mtr, знаете наверняка такие утилиты для того чтобы смотреть в Интернете красивые картинки.

Например, на ёлочку.

Или вот, ещё есть Звёздные Войны.

Или стихи про плохую лошадь.

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

Естественно, можно наблюдать и цикл маршрутизации. В данном случае пакет сначала шёл нормально по цепочке маршрутизаторов, а потом в какой-то момент зациклился между двумя маршрутизаторами, один из которых не отвечает ошибками, а второй отвечает исправно. Видно, что пакет ходит между ними бесконечно. Кстати, данный конкретный пример это то, что сейчас можно увидеть вместо ёлочки показанной ранее. Так что ёлочка ушла, а хоровод остался.

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

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

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

Эта конкретная проблема скорее относится ко второму классу циклов, которые я назвал “ошибки конфигурации”. И я считаю, что это наиболее популярный вариант, когда у нас есть какие-то неиспользуемые адреса или NAT-пулы используются, которые не терминируются нигде. 

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

Подобные циклы уже долговременные и до тех пор пока ошибка не будет устранена они будут приводить к проблемам.

Конкретно такую ошибку можно легко исправить на стороне клиента, если мы все адреса которые получаем от провайдера null-route’им. Таким образом этот маршрут у нас будет служить своеобразным fallback’ом. Причем такое делать лучше всегда, даже если вы используете все эти адреса. К примеру, есть оборудование, которое если у вас физический линк падает и это единственный линк относящийся к VLAN’у, то vlan тоже будет в состоянии down. Таким образом маршрут пропадет и вы получите цикл на этот промежуток времени, пока линк не восстановится. Поэтому лучше такой route добавить, с какой-нибудь большой метрикой в качестве fallback’а.

И на стороне провайдера, также, в некоторых случаях, если вы можете к клиенту применить политику антиспуфинга, например это одноногий (стаб-сеть) клиент, то такое лучше сделать в любом случае. И в данном случае это поможет вам разорвать цикл маршрутизации, потому что пакет который вернется от клиента уже будет с source’ом не из его сети, скорее всего.

Какие проблемы могут быть от циклов маршрутизации?

Самая очевидная проблема - это повышенная загрузка канала. Например, если у нас есть цикл длиной 2 и туда прилетает TTL 200, то он сто раз по этому циклу пройдет и мы получим стократное увеличение трафика на этом цикле. И такой цикл может быть целью атаки на отказ в обслуживании. Или если, например, это цикл между вами и вашим провайдером, то он может посчитать этот трафик и вы просто заплатите за него.

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

Я нашел несколько, как мне показалось, интересных статей по проблематике циклов. Первая статья (https://www.usenix.org/legacy/event/imc05/tech/full_papers/xia/xia_html/imc05-paper-128-final.html) как раз описывает возможность загрузки канала малым трафиком при наличии цикла. Второй материал (https://www.usenix.org/system/files/sec21fall-bock.pdf) не совсем про циклы - товарищи пытались использовать миддлбоксы, это обычно коробки, которые осуществляют какую-то фильтрацию или сбрасывают TCP-соединение, то есть отвечают на проходящие мимо пакеты, для организации отраженных атак. И такие коробки в сочетании с циклами в состоянии давать амплификацию, потому что пакет проходит несколько раз мимо такой коробки и она каждый раз что-то посылает в ответ. И в некоторых случаях они наткнулись в том числе на бесконечные циклы, то есть они описывают, что в одном случае они получали ответный трафик в течение шести дней после того как прекратили от себя посылать трафик, они предположили что пакет просто дропнулся и трафик перестал приходить.

И еще есть статья (https://mkorczynski.com/PAM17Lone.pdf) об обнаружении возможности спуфинга сети в случае наличия циклов. Дальше, довольно интересная статья вышедшая недавно (https://blog.benjojo.co.uk/post/bgp-stuck-routes-tcp-zero-window), в которой описывается механизм как BGP-сессия может залипнуть таким образом, что keep alive проверки не обнаружат этого и таким образом данная сессия может долго просуществовать в залипшем состоянии, с залипшими маршрутами. И в последней статье (https://toonk.io/the-risks-and-dangers-of-amplified-routing-loops/index.html) предлагается использовать совокупность обычной амплификации с циклом, то есть направлять трафик с амплификации в цикл, таким образом достигать кумулятивного эффекта и совсем малым трафиком осуществлять загрузку вашего канала.

Собственно, после этой статьи, комментарии к которой я читал и где был некоторый скепсис насчет того насколько реально использовать с этой целью циклы, я решил сделать этот доклад.

В том числе я вспомнил пример из собственной практики, больше четырех лет назад, с моим домашним провайдером. Я обнаружил цикл в их сети и написал им об этом, привел traceroute где явно видно цикл. В ответ мне, естественно, написали “иди отсюда глупый пользователь, ты ничего не понимаешь, это у нас такой NAT-пул и у тебя внешний адрес не должен работать, а если бы это был цикл маршрутизации, то наш мониторинг его бы заметил”. Ну я предположил, что если у них есть такой мониторинг, то он, наверное, сломан, раз он цикл не заметил - они мне ничего не ответили, я следом написал по контактам из RIPE, на что мне ответили достаточно интересную вещь, мол “техподдержка правильно написала, потому что это не цикл по определению (с их точки зрения), адреса из NAT-пула просто нигде не сконфигурированы, поэтому они отправляются по умолчанию. Это можно исправить, но проблема косметическая и не стоит усилий”.

Это 4 года назад было, цикл всё ещё там - я проверил перед докладом, ребят не сильно беспокоит.

Теория - теорией, я решил проверить на практике действительно ли циклы вызывают проблемы, так как это может быть не всем очевидно. Собрал некоторый сетап из двух свитчей и трёх серверов, между свитчами у меня был цикл. Линк между свитчами 40 гигабит, между серверами и свитчами по 10 гигабит. Один из серверов с nginx’ом, со второго сервера я подавал тестовую нагрузку, а с третьего запускал флуд.

Примерно такими командами тестил - утилитой ab, в сто потоков, 5 минут тестил запросы, и флуд hping’ом запускал с разным размером пакета, с разной скоростью и направлял в сервер напрямую, либо в цикл.

Здесь можно видеть полученный график загрузки каналов. Слева линейный график, справа логарифмическая шкала. Голубенькое это трафик флуда, а зелененькое это график загрузки канала между свитчами. С правой стороны, где я уже начал загружать канал в цикле, можно видеть что синенькое - где-то на два порядка меньше трафик и он вызывает полную загрузку канала в цикле, примерно в сто раз.

Можно посмотреть дальше - в табличке. Если я, к примеру, брал 450 мегабит флуда и направлял его в сервер напрямую, то это, естественно, не оказывало никакого значимого эффекта на работу сервера. А в случае с циклом это приводило к полной загрузке канала между свитчами и я получил замедление в 5 раз, чуть больше. В некотором смысле для меня было некоторым удивлением то, что когда я пытался загрузить цикл маленькими пакетами, то я обнаружил что это не оказывает влияния - там 30 гигабит, но маленькими пакетами это полностью загруженный канал. Скорее всего это связано с тем как в свитче реализована очередь между портами, она скорее всего какая-нибудь честная и наверняка выбирает пакеты по очереди. Так как пакеты в цикле и полезный трафик приходят с разных направлений, то проходит все без проблем.

Тем не менее, несмотря на это, в случае с большими пакетами, может быть заполняется буфер или что-то ещё, проблему удается воспроизвести. И в случае если у вас, к примеру, это будут не коммутаторы, а какие-нибудь честные маршрутизаторы или серверы, то там другие узкие места и вполне возможно что проблемы будут гораздо более существенные.

В Qrator Labs у нас есть проект Radar, где мы наблюдаем за разными проблемами в Интернете и коллеги мне предоставили историческую статистику по количеству наблюдаемых циклов в IPv4 сегменте. Я нанёс на график и видно что тренд нисходящий, что наверное хорошо, многообещающе. Надеюсь они не перемещаются постепенно в IPv6.

Кроме того я решил провести своё собственное исследование. Первый раз я просканировал все адреса в Интернете с помощью четырёх ICMP-проб с разными TTL’ами и когда я получал ошибку TTL exceeded, то я считал что наткнулся на цикл. Таких адресов я обнаружил более 28 миллионов - это больше 1% от всех активных адресов в Интернете.

Причём, это скорее всего нижняя оценка, потому что не все маршрутизаторы отвечают ошибками, также часто попадаешь в лимиты и возможны потери пакетов и так далее. Глядя на полученные результаты было видно, что есть соседние адреса с пробелами и когда я пытался посмотреть эти адреса, есть ли там цикл, то он там был - и он не попал в результат.

1% адресов это уже достаточно много, но если посмотреть на то, в каких автономных системах содержатся циклы, то мы получим ещё более страшную цифру в 25 000 автономных систем, содержащих такие адреса. Это больше трети всех автономных систем в интернете на момент исследования. Причем правило Парето сильно нарушается - двадцать самых крупных автономных систем по циклам, это меньше 0,1%, дают как минимум 17% циклов. Причем там можно встретить самые разные автономные системы, государственные учреждения, институты, хостеры, производители мобильных телефонов. И что самое неприятное с моей точки зрения - это наличие циклов в сетях операторов поставщиков услуг доступности, это операторы CDN и защиты от DDoS-атак.

Причем не только маленькие организации, но и крупные и широко известные компании.

На данном графике можно видеть топ-20 автономных систем с циклами. Видно, что существенными лидерами являются какая-то национальная Интернет сеть Индии, в которой почти 600 тысяч маршрутов с циклами, на втором месте Lumen, причем у Lumen на самом деле несколько автономных систем и из них две умудрились попасть в топ-20. Если их сложить, то в сумме получится даже больше 600 тысяч.

Как я уже упоминал, встречается такое явление, как амплификация. Причем, в моем случае я смотрел только на полученные ошибки (TTL exceeded), то есть это не та же самая ситуация, что описана товарищами с мидлбоксами. Даже только с ошибками встречается амплификация. Я посылал по 4 пробы - а в ответ я получил в среднем больше 4 ответов на один адрес, естественно из тех на которые я получил хоть какой-то ответ. В некоторых случаях у меня было больше ста тысяч ответов на одну пробу. Если посмотреть самый активный маршрутизатор, от которого я получал ответы, то он в ответе за более чем 6% полученных мною ответов, массивная доля. И он такой не один, просто самый активный, в результатах выделяется несколько очень активных маршрутизаторов.

Есть также разные варианты, иногда можно получить несколько ответов с одного адреса на одну пробу, можно получить несколько ответов с разных адресов на одну пробу. Иногда бывает ситуация, когда прилетает несколько ответов с пары адресов, после чего это заканчивается ответом ещё и с третьего адреса. И причем это повторяющийся паттерн, встречаются очень странные ситуации.

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

И если мы посмотрим какие маршрутизаторы отвечают, то более полумиллиона маршрутизаторов в этих циклах участвует, из 20 000 автономных систем.

Что касается характеристик циклов, то длина циклов которые я нашел - от одного до 34 хопов. И больше половины этих циклов составляют циклы длиной 2 хопа. По распределённости/распространённости циклов - можно найти циклы величиной до 7 автономных систем, или до 8 стран, естественно с поправкой на геолокацию, но примерно можно оценить. Если смотреть по времени, то самый длинный цикл который я видел занимал до 18 секунд, причем они были из одного хопа. Циклы из двух хопов - до 8 секунд. Такие циклы даже mtr’ом сложно посмотреть, потому что он больше 10 секунд не принимает ответы и не показывает - можно увидеть только первый виток цикла. Мне пришлось пользоваться tcpdump'ом, то есть я реально посылал ICMP-пробы с увеличивающимся TTL и с каждым увеличивающимся TTL я видел, что ответ начинает приходить на 18 секунд дольше. Где там блуждают пакеты все это время я даже не знаю.

Естественно, кроме этого было много трансконтинентальных циклов, с понятными временами вроде полсекунды, 300 миллисекунд.

Здесь я отобразил статистику по странам на карте мира и топ-10 стран. США абсолютный лидер, там содержится больше 6 миллионов циклов, у остальных уже существенно меньше. Из региона ENOG в десятку попала только РФ.

На этом слайде статистика по ENOG-региону, топ-10 стран. Россия естественно первая, дальше Украина с существенным отрывом, то же самое с Казахстаном, остальные уже идут группой.

Я еще посмотрел статистику по автономным системам - по операторам поискал у кого больше всех циклов содержится, после четырех мне надоело листать - там уже существенно меньше, но топ рейтинга выглядит вот так: Ростелеком, Киевстар, Kcell и Транстелеком. Это только ENOG-регион.

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

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

Есть еще вот такие интересные циклы - состоит из 17 хопов, но 15 отсутствуют, просто не отвечают. Только два хопа отвечают.

Самое максимальное сколько я видел - это когда не отвечают 16 хопов в цикле из 33.

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

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

Самый странный цикл, который мне удалось обнаружить, выглядит вот так. Цикл длины 14, предположительно задействованы 7 маршрутизаторов (7 адресов). И как минимум из трех автономных систем вот по такой странной траектории ходит этот цикл. Я даже не знаю что это, мне кажется случайно такое нельзя сделать, единственная идея которая мне пришла в голову, это что кто-то взял в рабство сетевого администратора и он тайное послание оставил, чтобы его нашли.

Если вас это всё взволновало и вы занервничали, решили проверить нет ли в вашей сети циклов - вы можете просто зарегистрироваться у нас в Радаре и не искать циклы самостоятельно. По своей автономной системе вы получите информацию не только по циклам, но и по амплификаторам, BGP-инцидентам и другим вещам.

Спасибо за внимание!

Видео презентации доступно по ссылке.

Комментарии (12)


  1. amarao
    12.11.2021 20:35
    +5

    Ещё надо учитывать, что примерно половина всего интернета маршрутизируется не с помощью BGP, а с помощью денег и всяких систем массажа трафика, которые "лучше" знают, куда слать пакеты. Они могут поглядывать на BGP, а могут и сами принимать решение.


  1. mk2
    13.11.2021 10:54

    Попробовал traceroute bad.horse — у меня тоже не работает. Может, с июня он тоже сломался. Или это конкретно у меня.


    1. user318
      13.11.2021 20:18
      +1

      Оно плохо работало, на время появляется только. Я сначала тоже думал, что уже не работает. Но потом кто-то сказал, что у него всё ок. Надо mtr запустить и долго подождать попробовать, если сразу не показало.


  1. vviz
    13.11.2021 18:23

    Совет - направить маршрут в null. А где на реальном маршрутизатор взять gw null?


    1. user318
      13.11.2021 20:14
      +3

      А что за маршрутизатор у вас? Обычно реализованы маршруты в null или blackhole. Например "ip route <net> Null0" на цисках или ip route add blackhole <net> в линуксе.


      1. vviz
        13.11.2021 20:37

        Микротики у меня.


        1. ramax
          13.11.2021 20:43
          +3

          /ip route add type=blackhole

          Как-то так


          1. vviz
            13.11.2021 21:12
            +1

            Да, действительно. Спасибо.


  1. merlin-vrn
    14.11.2021 20:20

    Картинка с семью маршрутизаторами очень напомнила неустойчивый замкнутый цикл, какие случаются в режиме хаоса во всяких системах вроде бильярда Синая. На множестве Мандельброта тоже можно увидеть похожие картинки, если траектории строить, а не просто "не уходит/уходит/как быстро уходит", только там циклы устойчивые.


  1. NshAnton
    15.11.2021 15:51
    +1

    Спасибо, интересно. Цикл это тот же блэк холл, но с лишней суетой перед смертью пакета))

    В обычной жизни, цикл очень редко вызовет перегрузку оборудования, т.к. Трафик состоит из маленьких 40 байтных TCP SYN пакетов, если это не дос конечно.


  1. loginex
    16.11.2021 17:42

    Циклы чаще всего возникают из-за неправильной настройки, либо из-за того, что запрашиваемый адрес из-за аварии стал недоступен, но до него есть настроенная маршрутизация (статическая, как правило, либо залипший бгп). И как только это становится проблемой, тогда это начинают чинить, прописывают маршруты в null, но везде солому подстелить нельзя, поэтому проблема в текущей версии IP и протоколов маршрутизации (статика, бгп, оспф) останется.

     

    Что касается анализа, то делать это на неподконтрольном участке сети, прямой путь игры в угадайку. Ну например мы трейсим/пингаем адрес, а он находится за натом + в цепочке маршрутизаторов, у этих маршрутизаторов непубличные адреса могут быть, трейсим может быть мы вполне реальный публичный адрес, который, возможно даже(а может и нет), принадлежит конкретному хосту, но по пути маршрутизаторы будут нам отвечать со своих 192.168.0.1, 1.1, 2.1 и неизвестно каких адресов, нат это все дело оттранслирует, и мы получим ответ от адреса из NAT-пула :) Конечно, так мы поймем, что кольцо есть, но между кем и кем - эта информация будет покрыта мраком. Это может относиться к слайдам 32 и 33.

     

    Еще мы можем захотеть потрейсить адрес, который находится за устройствами, которые не отвечают на ttl-exceeded - мы не получим информации о петле; не уменьшают ttl при проходе через маршрутизатор - не будем знать, что кто-то маршрутизировал пакет между узлами; специально меняет ttl на статический или заведомо уменьшает или увеличивает - это вовсе будет ломать картину и покрывать все мраком(слайд 29-30), что в добавок может приводить к бесконечным петлям, но случайно такое редко делают; может проходить через устройство, которое не маршрутизатор, но меняет ttl, чтобы уберечь себя от петель - например это может быть прозрачный NAT в режиме бриджа, он может уменьшать ttl и отвечать, а может не отвечать. Да и еще много чего может быть, может быть маршрутизация на основе не адреса назначения, а на основе адреса источника (сорс роутинг)(слайд 32-33), а адрес источника или назначения может поменяться на NAT(или если его развернуть на 180 градусов - на балансировщике).

    Вообще в моей практике было так, что пакет приходил из Интернета, попадал на пограничный маршрутизатор, там был маршрут статический на NAT, проходил через NAT, там адрес назначения менялся(трансляция была создана исходящим пакетом из ЛВС в Интернет перед этим), дальше маршрутизатор в ЛВС получал пакет, но сеть, куда он должен был отправить его, стала внезапно недоступна, выпала из bgp, но у него был адрес по умолчанию - в Интернет! Теперь тот же пакет попадал в NAT уже со стороны локальной сети, но адрес назначения у него оставался старым (адрес из NAT-пула), поэтому пограничный маршрутизатор снова его отправлял в NAT, и так пока по ttl не убивал кто-то пакет.

     

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

    Представим себе путь адрес1 -> маршрутизатор1 -> маршрутизатор2 -> маршрутизатор3 -> адрес2, в другую сторону путь будет как адрес2 -> маршуризатор3 -> маршрутизатор4 -> маршрутизатор1 -> адрес1. У маршрутизатора2 и 4 будут еще и другие интерфейсы (не зря же они - маршрутизаторы), и допустим, если на адрес1 у маршрутизатора3 будет неверный маршрут (или маршрут через линк, где есть авария), то ответный пакет с ttl-exceeded адрес1 не получит, но трафик при этом будет ходить в обе стороны исправно. А если и ответ все же дойдет, то он будет с ip интерфейса, который будет отличаться от адресов на линках с маршрутизатор1 и 3. Входящий и исходящий трафик в Интернете очень редко (ну очень) проходят симметричный путь.

    А что касается того, что основные петли у AntiDDOS и CDN – то это может объяснить балансировщиками и прочим аналогичным оборудованием, на который маршруты прописаны статически на одном пути, а на другом нету маршрута в null, как в моей истории выше.


    1. user318
      16.11.2021 22:44

      Ну да, там есть много проблем, которые приводят к забавным артефактам. Про это даже можно вполне научные работы писать (научным руководителям на заметку). И, конечно, в рамках презентации охватить все аспекты практически невозможно. Спасибо, что дополнили и добавили для не столь искушённых читателей информацию про разные нюансы работы с трассировками и TTL. Кстати, на просторах сети точно есть бесконечные циклы с вмешательством в TTL — упомянутое исследование с мидлбоксами об этом свидетельствует, но там их видно по побочным эффектам. А простыми пробами, наверное, их не обнаружить, как и многие другие циклы наверняка остались незамеченными, как я говорил - не всегда приходит такой ответ из цикла по разным причинам. Но если откуда-то пришёл ответ, то, думаю, что с большой долей уверенности можно считать, что цикл там есть.

      Это всё не отменяет основных выводов касательно количественных и качественных характеристик. Т.е. с утверждением про то, что анализ можно делать только на подконтрольком участке сети, я позволю себе не согласиться. Да, точные данные получить таким сторонним наблюдением не получится или очень затратно, но оценочные суждения делать вполне можно.