RIP BGP

В октябре 2024 года, я выступал на тематической конференции Linkmeetup с докладом. Внезапно, он занял первое место в голосовании и меня настоятельно попросили оформить это всё в виде статьи. Ниже, прошу её к вашему вниманию.

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

• BGP всё? Нет, конечно. BGP — наше всё. На мой взгляд, это лучший из имеющихся механизмов для передачи маршрутной информации. Максимально гибкий, адаптивный, функциональный и прочие «ий» и «ый».

• Это было в проде? Нет, это история из лаборатории.

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

Дополнительно, дам справку по тем терминам, которые буду использовать ниже:

Underlay — опорная сеть или транспорт, поверх которого строится всё остальное;
Overlay — сервисная часть, или сеть внутри которой ходят наши VPNы и вcе хосты между собой взаимодействуют;
BUM — сокращение от broadcast, unknown unicast и multicast. Тип трафика, который возникает внутри сети и тот механизм, с помощью которого обеспечивается его доставка;
DCI — datacenter interconnect, участок сети и соответствующий ему набор технологий, позволяющий соединять между собой сайты;
EXT — внешняя сеть, условная граница VXLAN-EVPN, откуда к нам могут приходить префиксы 0.0.0.0/0 и т.д.

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

Часть первая. Погружение

Рассказ начну немного издалека. За прошедшие несколько лет я принял участие в построении нескольких десятков фабрик разных масштабов. Если посмотреть по верхам, то можно отследить несколько крупных и достаточно ключевых проектов.

Проект №1.

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

Как вы видите, дизайн был выбран стандартный. Всё это на тот момент было стандартной рекомендацией от Cisco, да и сейчас если что, очень даже неплохо работает.

Проект №2.

Успех первого проекта видимо дал свой результат и к нам обратились ребята покрупнее. Теперь задача выглядела чуть шире, нужно было не только модернизировать ЦОД, но ещё и расширить его новым сервисом.

Мы подошли к этой задаче основательно. Собрали стенд и тщательно исследовали его. В результате увидели, что IS-IS работает не так как нам хочется, зато вот OSPF отлично себя проявил. Обратились к вендору, они нам подтвердили опасения и быстренько валидировали новый дизайн, где в underlay уже крутится OSPF.

Получилась история немного отличная от предыдущей, но всё так же не сильно уникальная. Ну да, добавили стык с MPLS, ну да, поменяли IS-IS на OSPF, но в остальном всё тоже самое.

Проект №3.

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

Тут нам пришлось очень глубоко покопать в пучинах китайской документации и исследовать в лабе. Честно, это было очень непросто. Документация Huawei очень скудная по данной теме и совсем не включает в себя сценарии включения других вендоров, впрочем как и Cisco, да и вообще любого другого вендора.

Но в конечном итоге, всё получилось. В качестве передачи BUM мы уже на стороне Huawei использовали IR (ingress replication), для underlay eBGP, а для overlay iBGP. Интересно то, что только Huawei позволяет это делать в разных инстансах и запускать параллельно 2 BGP процесса. Очень удобно.

Собственно сайты больше, а в андрелее уже не только бывает OSPF или IS-IS, но ещё и eBGP.

Проект №4.

Пришёл 2022 год. Импортозамещение пришло вместе с ним.

Не буду тут описывать детали всего проекта, подробно всё было на моём первом докладе, вот тут — https://youtu.be/MIW8IQhesaM

Коробки, которые мы использовали, построены на Broadcom Trident3-X7, и очень хорошо дружат со сценариями eBGP-only, мы это подтвердили и в тестах, и от вендора, да и вся индустрия за последнее время. Не стали идти наперекор, сделали так. В итоге вот что получилось.

Как видите, это было больно. Причем больно для всех. И для нас, и для Заказчиков, и для вендоров. Но в итоге тоже всё получилось и данная сеть работает по сей день.

Проект №5.

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

Нюанс №1. Заказчик хотел себе только связку IS-IS + iBGP в рамках underlay/overlay. Если с оверлеем никаких проблем, то с андрелеем они были.

Нюанс №2. Было требование по некоторым «интересным» сервисам, в рамках которых мы делали overlay через overlay…

Нюанс №3. Дополнительную боль, вызвал ещё момент с оптимизацией стыков через Option-A.

В итоге, даже такой сценарий был реализован корректно и успешно. Тут уже без схем. Частично они были описаны в моих более ранних постах вот тут и тут.

Промежуточный итог

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

Если посмотреть на них вместе, то можно выделить следующее:

• Ни одного полностью одинакового дизайна

• Каждая архитектура показала превосходный результат и полностью удовлетворила требования заказчика

• За всё время эксплуатации вышеописанных сетей, ни у одного из заказчиков, не возникло желания перейти на другой набор технологий и протоколов

И тут, я хотел бы подвести всех вас к следующим мыслям:

• А действительно ли вам нужны все «новые» технологии?

• Насколько тот же SRv6 поможет вашему бизнесу в решении задач?

• Как часто у вас вообще случаются сбои в сети, и точно ли они по причине маршрутизации?

• Действительно ли у вас такой масштаб, что только дизайны ЦОДов пришедшие из Facebook будут для вас актуальны? (отсылка к RFC7938)

• И многое, многое другое…

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

Собственно тут я предлагаю перейти ко второй части, которая касается непосредственно самого исследования.

Я её озаглавил фразой писателя-фантаста Владимира Савченко, «Прежде чем делать открытие — загляни в справочник (с)».

Часть вторая. Прежде чем делать открытие — загляни в справочник (с).

Как вы уже догадались, я вам не просто так до этого рассказывал про определенный набор технологий и решений. Говорить дальше будем тоже про них, а конкретно про EVPN-VXLAN.

Как говорится…

Собственно, как я ранее озвучил, у нас есть несколько плоскостей — underlay и overlay. Плюс есть ещё особенность распределения BUM трафика. Мы можем этими вещами управлять и выбирать те протоколы и механизмы, которые будут работать внутри нашего дизайна. Однако, если говорить про BUM или overlay, то тут вариантов практически нет. Грубо говоря, их всего 2 для BUM — ingress replication и multicast, и также 2 для overlay — iBGP и eBGP. Больше выбора то и нет. Причем, часто, работает только какой-то один.

Зато у нас масса вариантов для построения underlay — это и будет цель нашего исследования.

Для наглядности, небольшая картинка, с описанием тех требований, которые у нас есть к плоскости underlay.

Значения которые я привёл выше, взяты из нескольких наших проектов и соответствуют тем требованиям, которые к ним выставляются. Естественно, они не являются абсолютно верными и совершенно точно могут отличаться, как в большую, так и в меньшую стороны.

Отдельно, ещё хочу заметить, что на мой взгляд чем система проще, тем она стабильней. Меньше звеньев – меньше чему ломаться и проще (быстрее или дешевле) чинить.

Собственно, задача сформирована. Пора приступать.

Исследование будем проводить в качестве сравнения разных популярных и не очень протоколов, которые я ранее описывал.

Конкретно взял следующие:

• OSPF

• IS-IS

• BGP

И…

Прошу любить и жаловать!

Протокол, который победил саму смерть!

Протокол, которому в этом году (2024) исполняется 55 лет!

И это, никто иной, как

RIP.

Из плюсов, это самый простой протокол динамической маршрутизации по моему мнению. Да он называется — Routing Information Protocol или Протокол Маршрутной Информации. Что может быть проще?

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

Ну и отдельно, я предлагаю вам рассматривать его не в ключе, чем он хорош, а «Чем он нам не подходит?».

Собственно, тут стоит озвучить все его минусы. Я выделил 4:

• Максимальное количество хопов — 16

• Время реагирования — multiplayer от таймера response (по дефолту 3 минуты)

• Каждый пакет — это полный набор маршрутной информации

• Отсутствие всяких фич и прочих «приколов».

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

Давайте пойдём по порядку и рассмотрим каждый из минусов, описанных выше.

Ограничение в 16 hop.

Как вы прекрасно знаете, если маршрут передать больше 15 раз, то на 16 он будет признан недостижимым и если говорить про какую-то большую сеть, это действительно становится проблемой.

Но, мы говорим про ЦОДы, а конкретно про underlay. Давайте посмотрим что же действительно будет происходить в нескольких разных сценариях, если топология будет CLOS.

Вариант 1. 3-tier Clos. Штатная ситуация.

Трафик идёт от leaf-1 до leaf-2, максимальное количество хопов равняется 3, ну нас это более чем устраивает.

Ок, смотрим дальше.

Вариант 2. 3-tier Clos. Максимально возможный отказ.

Предположительно у нас разорвалась куча линков и количество хопов выросло до максимально возможного значения, при которого связь всё-таки сохраняется. Как видите, даже в такой ситуации мы видим значение равное 5. Ну, тоже ок.

Ладно, что я вам всё про 3-tier, когда раньше сказал про 160 коробок. Давайте смотреть 5-tier.

Вариант 3. 5-tier Clos. Штатная ситуация.

Тут разницы большой нет, тоже 5 хопов. Давайте что-нибудь сломаем.

Вариант 4. 5-tier Clos. Частичный отказ.

Сломал несколько выборочных линков, спровоцировал тем самым рост количества хопов до 7. Всё ещё допустимо…

Вариант 5. 5-tier Clos. Максимально возможный отказ.

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

Какой вывод можно сделать?

Правильно. Нас всё устраивает. И этот минус для нас совершенно не актуален.

Идём дальше. Смотрим пункт 2.

Время реагирования – вечность.

Тут предлагаю не заниматься изобретением велосипедов и просто посмотреть на аналогичные примеры. Конкретно, у нас есть протокол, который имеет ровно такие же таймеры по умолчанию и вы не поверите кто это — eBGP.

Тоже 60 * 3 = 180 секунд.

Как вы все прекрасно знаете, благодаря всем известному RFC9738, он приобрёл огромную популярность, в котором однозначно определены таймеры для актуальности внутри ЦОДа, а именно 10 * 3 = 30 секунд.

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

Для наглядности, вот топология выше, но показанная под немного другим углом.

Параметры теста будут следующие:

ECMP включен

Профиль трафика:

• L3

• однонаправленный

• поляризованный

• pps = 138210

• пакеты = 9000 байт

Сам тест схематично будет выглядеть вот так:

• Трафик проходит по выбранному направлению, постоянно фиксируется количество отправленных и полученных пакетов.

• Мы рвём линк между spine-1 и leaf-2. Фиксируем отказ и ждём восстановления.

• После восстановления останавливаем тест и фиксируем количество отправленных и полученных пакетов. Так как PPS фиксированный, то мы можем очень точно получить то время, которое пакеты не приходили.

• Заполняем полученные данные в таблицу и повторяем тест для другого протокола.

Все таймеры, которые используются, являются по сути рекомендованными значениями для сетей внутри ЦОД. Для OSPF и IS-IS — это дефолт, 10 * 4 и 10 * 3, соответственно. Для BGP и RIP — писал выше, 10 * 3.

Вот такие результаты я получил.

Как видите, RIP совсем не так уж и плох в сравнении с другими протоколами.

Что получается, это нас полностью удовлетворяет?

Хм. Разве кого-то из вас, устроит отказ длиной в 30 секунд? Ну или пусть даже 20?

Не уверен. Да и в самом начале, когда мы ставили задачу, я указал те таймеры, которые нас удовлетворят — 999 мс. Всё что больше — авария.

И тут вы прекрасно сами уже наверняка поняли, что ни один из вышеописанных протоколов самостоятельно никак не решает данную задачу. Для этого существует BFD, который отлично поддерживается в связке с RIP.

В итоге эта проблема тоже для нас неактуальна.

Смотрим дальше и наш третий пункт.

Каждый пакет — это полный набор маршрутной информации

Для наглядности, вот вам картинка.

Очевидно то, что для маршрутизации в Интернете — RIP ну совсем никак не подходит. Никому не захочется получать раз в несколько секунд full view.

Ранее, я указал что предполагаемый ЦОД, будет иметь масштабы в примерно 160 узлов. Если прикинуть, то получается ориентировочно 450+ маршрутов, с учетом loopback и p2p.

Идём на стенд.

Схематично тест будет выглядеть вот так:

• сначала делаю редистрибьюцию в настроенный протокол 450 маршрутов

• дальше включаю tcpdump

• делаю reset сессии

• жду 60 секунд и прекращаю tcpdump

• анализирую и собираю всё в таблицу.

В итоге получилась вот такая картина:

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

Как видите RIP тут совсем не в лидерах, в какой-то степени даже проигравший. Правда если посмотреть на тот объём данных, которые передаёт IS-IS с дефолтной настройкой padding, то выходит в 4 раза больше, чем RIP.

Любопытно 🙂

Ладно, давайте теперь подумаем серьёзно.

Скажите мне, только пожалуйста честно, насколько для вас актуальна разница между передачей 18 пакетов и 45 Кб и допустим, в случае с BGP 18 пакетов и 3 Кб?

Вот серьёзно. У нас 100 Гб/с на Trident-3-x7. Мы реально хотим размышлять об экономии передачи СОРОКА ПЯТИ КИЛОБАЙТ и ВОСЕМНАДЦАТИ ПАКЕТОВ?

На мой взгляд проблема немного преувеличена.

Такс. Это был пункт номер 3. Остался последний.

Отсутствие всяких фич и прочих «приколов»

Тут на самом деле нет абсолютно точной картины, так как бывают варианты и вполне вероятно, что ваши требования смогут отличаться, но я отталкивался от среднестатистической сети EVPN-VXLAN. Вот что получилось:

• ECMP

• P2P authentication

• Возможность управлять маршрутами

• Возможно что-то ещё…

ECMP — отлично поддерживается всеми протоколами, в том числе и RIP.

P2P authentication доступна из коробки и все вендоры это у себя реализовали.

Маршрутами управлять можно, добавляя те самые hop, и как вы помните у нас есть в запасе несколько.

Возможно что-то ещё? Я подумал и скажу так. Никакие LFA, CSPF и прочие «сложные» штуки, мы не делаем в underlay.

Ну и для наглядности вот вам картинка.

В результате, все тесты пройдены, а требования выполнены.

ДА ЧТО ВАМ ЕЩЁ НУЖНО? ОН ИДЕАЛЕН

В результате, мы видим, что протокол использовать можно, а делать это или нет — уже решайте сами.

Наконец-то мы подходим к финалу.

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

И как полагается, завершу это всё фразой, автора которой я не знаю, но которая мне очень понравилась:

Инженерия — это не просто знание и не просто искусство, а искусство применения знания.

---

На этом всё!

Надеюсь, было интересно, подписывайтесь на https://t.me/like_a_bus_channel, будет ещё.