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.
Получается достаточно сложный interop, что в целом всегда не простая задача. Те кто сталкивался, прекрасно меня поймут :).
Тут нам пришлось очень глубоко покопать в пучинах китайской документации и исследовать в лабе. Честно, это было очень непросто. Документация Huawei очень скудная по данной теме и совсем не включает в себя сценарии включения других вендоров, впрочем как и Cisco, да и вообще любого другого вендора.
Но в конечном итоге, всё получилось. В качестве передачи BUM мы уже на стороне Huawei использовали IR (ingress replication), для underlay eBGP, а для overlay iBGP. Интересно то, что только Huawei позволяет это делать в разных инстансах и запускать параллельно 2 BGP процесса. Очень удобно.
Проект №3
Собственно сайты больше, а в андрелее уже не только бывает OSPF или IS-IS, но ещё и eBGP.
Проект №4.
Пришёл 2022 год. Импортозамещение пришло вместе с ним.
Не буду тут описывать детали всего проекта, подробно всё было на моём первом докладе, вот тут — https://youtu.be/MIW8IQhesaM
Коробки, которые мы использовали, построены на Broadcom Trident3-X7, и очень хорошо дружат со сценариями eBGP-only, мы это подтвердили и в тестах, и от вендора, да и вся индустрия за последнее время. Не стали идти наперекор, сделали так. В итоге вот что получилось.
Проект №4
Как видите, это было больно. Причем больно для всех. И для нас, и для Заказчиков, и для вендоров. Но в итоге тоже всё получилось и данная сеть работает по сей день.
Проект №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 — отлично поддерживается всеми протоколами, в том числе и RIP.
P2P authentication доступна из коробки и все вендоры это у себя реализовали.
Маршрутами управлять можно, добавляя те самые hop, и как вы помните у нас есть в запасе несколько.
Возможно что-то ещё? Я подумал и скажу так. Никакие LFA, CSPF и прочие «сложные» штуки, мы не делаем в underlay.
Ну и для наглядности вот вам картинка.
В результате, все тесты пройдены, а требования выполнены.
ДА ЧТО ВАМ ЕЩЁ НУЖНО? ОН ИДЕАЛЕН
В результате, мы видим, что протокол использовать можно, а делать это или нет — уже решайте сами.
Наконец-то мы подходим к финалу.
В заключении, хотел бы сказать следующее. На мой взгляд, залог успеха ваших заказчиков или бизнеса — в использовании того самого инженерного подхода к решению задач. Не бойтесь сомневаться и задавать себе вопрос «Почему?», а перед тем как что-то внедрять, не забывайте смотреть в справочник!
И как полагается, завершу это всё фразой, автора которой я не знаю, но которая мне очень понравилась:
Инженерия — это не просто знание и не просто искусство, а искусство применения знания.
На этом всё!
Надеюсь, было интересно, подписывайтесь на https://t.me/like_a_bus_channel, будет ещё.
