Опыт построения DPI IP/ECMP based фабрики на оборудовании Juniper QFX10k с применением symmetric hashing

15 Jul 2021 - somovis

Share on:

В данной заметке я хочу поделится опытом построения DPI блока сети передачи данных (PoD) на оборудовании Juniper QFX10k являющегося частью EVPN/VXLAN фабрики с применением IP/ECMP, symmetric hashing, resilient hashing.

Дисклеймер

В дальнейшем любые совпадения в названии производителей носят случайный характер :)

Определения

Вступление

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

Порой встречаются довольно интересные задачи, вот так и мне однажды посчастливилось, когда нам понадобилось построить для защиты определенного сегмента сети DPI блок СПД с применением IPS. Не буду вдаваться в подробности на этом моменте, нас же больше интересует техническое решение задачи.

Вот так выглядит целевая схема DPI блока СПД: target scheme png
Целевая схема в PDF
Если ты, уважаемый читатель, сразу ее понял и во всем разобрался, то можешь далее не читать. Но если у тебя остались еще вопросы, то милости прошу под кат.

Коротко опишу данную схему СПД:

Хочу обратить внимание, что данное техническое решение прорабатывалось в начале 2020 года, а схема тестировалась на разных платформах и моделях разных производителей, но сейчас уже появилось более дешевое/новое оборудование или обновление ПО для более дешевого оборудования того же производителя, которое тоже подходит для решения данной задачи, при этом, некоторое протестированное оборудование уже может быть недоступно для заказа.

ТЗ было примерно следующим:

Размышления

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

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

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

Рекомендую ознакомиться с данными технологиями перед дальнейшим прочтением материала.

Отсутствие кластеризации со стороны DPI устройств нам не повредит, но естественно будут особенности, подробнее в секции Проблемы.

Спустя какое-то время, занимаясь тестированием DPI платформ, мы увидели оптимальное для данной задачи решение в рамках одного устройства:

Высокая доступность

Прежде чем говорить о масштабировании, следует упомянуть высокую доступность, у данного термина есть следующее определение: “свойство системы быть защищённой и легко восстанавливаемой от небольших простоев в короткое время автоматизированными средствами.”. Не стоит путать данный термин с надежностью.

В мире телекоммуникаций высокая доступность достигается резервированием [1, 2] тех или иных компонентов. Есть следующие виды резервирования:

Не привычно, правда? Мы ведь давно привыкли, что:

Но есть ГОСТ, МЭК и прочие, в которых даются четкие определения.

Ладно, вернемся к миру телекоммуникаций и пропустим все виды резервирования, кроме привычных нам a/s, a/a.

active/standby

fo a/s
Классический вариант, используемый в большинстве корпоративных сетей, начиная от STP (да, его можно использовать не только как защиту от петель), резервирования шлюза средствами VRRP/HSRP и заканчивая резервированием устройства предоставляющее сервис. Ни для кого не секрет, что в данном виде резервирования часть устройств ждет аварии/переключения, чтобы перейти из режима ожидания в активный режим. В данном виде резервирования, как правило, используется группа из двух устройств (Cluster/MC-LAG) и этот вид резервирования больше подходит для scale-up масштабирования, потому-что других вариантов внутри группы из двух устройств попросту нет.

Плюсы:

Минусы:

active/active

fo a/a
А этот вид резервирования уже более интересен инженерам и операторским сетям, так как нагрузка распределяется между всеми устройствами в группе устройств (Cluster/MC-LAG/GLBP), но нельзя сказать, что всегда распределяется равномерно, особенно если это касается гео-распределенных кластеров (не нужно так, пожалуйста, берегите нервы себе и своим инженерам!).

Плюсы:

Минусы:

Масштабирование

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

Заядлый инжиниринг

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

Приведу простой пример: когда-то давно, когда еще не было EVPN (за исключением проприетарного GLBP), когда нужно было зарезервировать шлюз сети, требовалось использовать VRRP/HSRP на группе маршрутизаторов, при этом, только один из маршрутизаторов в данной сети мог быть активным для передачи трафика в направлении из данной сети (исключаем задачу с растянутым VLAN между разными площадками, активным VRRP на каждой площадке и фильтрации VRRP mcast/unicast между площадками). Поэтому, еще тогда придумали псевдо active/active, назначая активными разные маршрутизаторы для разных VLAN (точнее, разные приоритеты для разных VRRP Groups на разных маршрутизаторах), таким образом трафик из VLAN X шел в маршрутизатор 1, а трафик из VLAN Y шел в маршрутизатор 2, и так далее.

Если же мы говорим про управление трафиком между разными сегментами СПД, то это потребует дополнительных маркеров, по которым потом потребуется работать всю жизнь, а не единоразово их применить на сети и забыть навсегда. К тому же, со временем, при масштабировании, придется вносить изменения в маркировку и это вызовет перебалансировку трафика. Не говоря про сложность данного решения в автоматическом режиме, человеку, который только увидит документацию/конфигурацию, будет крайне не просто искать и исправлять потенциально возникшую проблему. В нашем случае мы имеем >100k активных SRC IP-адресов, разбросанных по всей сети (примерно ~10k префиксов) и им всем нужен доступ до сегмента, который мы защищаем. Поэтому, сказать какие маркеры применить на префикс, сколько полосы по факту будут утилизировать SRC IP-адреса за конкретным префиксом и сколько IP-адресов из префикса активно, и сколько будет активно завтра - практически невозможно, а сложность решения ты поймешь далее. В итоге мы отказались от данной опции.

scale-up

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

Конечно, у данного решения есть свои плюсы:

Но есть и минусы:

scale-out

scale-out
Горизонтальное масштабирование стало стандартом во многих отраслях за последние 10 лет, будь то масштабирование СПД, приложения или промышленного производства.

Плюсы:

Минусы:

Cluster

cluster
А вот и всеми любимые кластеры, наконец-то! Но не спешу радовать, мы будем говорить про кластеры в контексте DPI.

Кластер можно частично отнести к дизайну scale-out, так как позволяет масштабировать уже рабочий кластер добавляя в него устройства. Но, каждый кластер лимитирован тем или иным ограничением, включая количество устройств и жестко привязывается к конкретному производителю, а иногда и к платформе/модели устройства, поэтому, исчерпав ресурсы кластера, понадобится строить рядом еще один (чем-то похоже на дизайн PoD, когда, исчерпав ресурсы, строится рядом еще один).

Из плюсов сюда можно отнести следующее:

Конечно, кластер имеет свои существенные недостатки, например:

Для решения текущей задачи данный вариант нам не подошел, но, не исключено, что для другой задачи он подойдет. Хотя, после решения данной задачи, задаешься вопросом: “зачем?!”.

Все последующие варианты будут связаны с symmetric load balancing и resilient/consistent hashing, поэтому, если ты еще по какой-то причине не знаком с ними, то настоятельно рекомендую сперва ознакомится и только потом продолжать чтение данного материала.

MC-LAG L2 Transparent

mlag-l2-transparent
Один из самых простых и часто встречающихся вариантов. В данном варианте хорошо практически все - MC-LAG пара обеспечивает резервирование коммутаторов/маршрутизаторов, fw работают в прозрачном режиме, но есть один основной момент - если мы используем symmetric hashing и при этом происходит авария на любом линке к fw (например: между spine01 и fw01), то автоматически мы получаем асимметрию. Чтобы избежать данной проблемы, можно использовать детектирование аварии по линку на стороне fw и принудительно выключать зеркальный интерфейс (в данном примере это будет интерфейс между fw01 и edge01). Грубо, жестко, но позволит избежать асимметрии, однако, данный вариант уносит логику на fw и требует поддержки данной возможности на их стороне. Можно, конечно, еще красить пакеты и по DSCP значению принимать решение, но этот подход не будет масштабироваться.

Плюсы:

Минусы:

Минусы значительно превышают плюсы, идем дальше.

MC-LAG L2 Switched

mlag-l2-switched
Данный вариант продолжает все плюсы и минусы предыдущего варианта, но добавляет сложности, ведь, возникает проблема с BUM трафиком. Сразу минус и идем дальше.

MC-LAG L3 Routed w/ BGP

mlag-l3-routed
Вот, что-то уже интересное, не так ли? В данном сценарии у нас повторяется предыдущая схема, за исключением того, что fw превращаются в транзитные маршрутизаторы. На edge/spine:

Зачем нужно 2 BGP сессии и почему бы не поднять одну BGP сессию к виртуальному плавающему IP-адресу (VRRP/HSRP)? Потому, что, в случае аварии устройства, которое обслуживает в данный момент времени виртуальный IP-адрес, BGP сессия будет переустановлена на другом устройстве, это вызовет потерю трафика и отказ в обслуживании сервиса. Но, если поднять две BGP сессии от fw к паре коммутаторов одного уровня (edge/spine), то в случае аварии одного из коммутаторов, просто уберется NH из NHG, а потеря трафика будет менее значительной. При этом, если произойдет авария на линке, например, между fw01 и spine01, BGP сессия не упадет между данными устройствами, потому-что IP-адрес будет доступен от fw01 через spine02 по ICL. Да, перераспределятся hash-buckets, поменяется egress интерфейс, но результат прохождения потока будет сильно зависеть от конкретного силикона и ПО, а если точнее, то используется ли на устройстве иерархический ECMP/hashing, иерархический FIB, или нет.

Но, если мы получим асимметричное прохождение трафика, можно прибегнуть к решению проблемы, которое будет рассмотрено далее в секции ECMP w/ BGP.

Плюсы:

Минусы:

Вроде бы хороший вариант, а минусов с каждым разом все больше и больше, как же так.. А вот так :)

Вспоминая основы и де-факто стандарты построение современных сетей в ДЦ, можно придти к выводу, что, если смешать SP и DC технологии в одном флаконе, получится почти идеальное решение данной задачи. Идем к нему, осталось совсем чуть-чуть!

ECMP w/ BGP

Ура, наконец-то что-то простое! (нет)
ecmp-v1
Схема сверху хороша, если резервирование можно обеспечить целыми плоскостями, а не отдельными устройствами, но, в нашем сценарии и с нашей емкостью этот вариант стоит дороже, поэтому, сперва решили сделать резервирование устройств внутри плоскости, чтобы защитится от двойного отказа, как на схеме ниже, а только потом, после исчерпания ресурсов, добавлять новую плоскость.
ecmp-v2
Тут прекрасно всё! (почти)
Перейдем же к описанию принципа работы:

Что же, вроде все понятно, так почему большинство организаций до сих пор используют LAG, а не ECMP? Я думаю, дело в маркетинге, а может быть просто никому это не было нужно и все жили на scale-up. Но мы пришли к ECMP, и я повторюсь, аналогичных примеров использования ECMP я не нашел в русскоговорящем сегменте, а в англоязычном их были единицы и некоторые подразумевали sFlow аналитику прямо на коммутаторе с использованием самописных скриптов.

В данном сценарии все будет работать идеально, за исключением проблемы асимметричного прохождения трафика при одиночных отказах линков. Как ее решить? Первый вариант был описан в самой первой схеме с L2 и fw в прозрачном режиме, но, мы же не хотим переносить логику на fw. Пусть они останутся все теми же тупыми устройствами, но уже с BGP, BFD и ECMP. Кроме того, есть еще как минимум два решения данной проблемы, о которых будет в следующих подчастях, а пока подведем краткий итог.

Плюсы:

Минусы:

Ну что, плюсов много, осталось слегка доработать и с этим можно жить!

Tunneling GRE/IP-IP

Начинаем решать проблему асимметричного прохождения трафика с простого - с туннелирования.
ecmp-v3
Для лучшего понимания концепции немного перерисована схема, в которой наши существующие spine превратились в border leafs и к ним добавился еще уровень spine (ну не будем же мы туннелировать трафик для обхода проблемного линка через пачку leaf коммутаторов), а к уровню edge добавилась пара LSR, чтобы в нижней части схемы тоже была возможность использовать туннелирование для обхода проблемного линка.

Предлагаю рассмотреть путь прохождения трафика от spine коммутаторов до p маршрутизаторов на схеме ниже.

single-tunnel
В данном схеме отображена авария на линке между br leaf01 и fw01, при этом, от br leaf01 дополнительно установлен туннель до fw01, позволяющий обойти проблемный линк через альтернативный путь. Конечно, в большинстве случаев и для обходного туннеля можно будет использовать ECMP, как на схеме ниже.

multiple-tunnels

Это довольно хороший способ многократно зарекомендовавший себя, но, как видно по схеме, он требует дополнительного оборудования или изменения конфигурации сети ДЦ (сейчас CLOS дизайн, отсутствие BGP path hunting и все такое, построенное в лучший традициях), чего мы себе не могли позволить на тот момент. Кроме того, при использовании GRE могут возникнуть проблемы с offload на fw, особенно если у fw модульная архитектура внутри устройства (даже если устройство 1u, это не означает, что там будет обязательно 1 чип), поэтому и от GRE мы сразу отказались. А что на счет IP-IP? Это может показаться смешным, но мы его даже не тестировали на данном оборудовании в данном контексте, потому-что это все равно потребовало бы изменение дизайна ДЦ или покупки дополнительного уровня оборудования, кроме того, на наших QFX10k2 данная функциональность появилась только в 20.3 ветке ПО, которую нужно тестировать отдельно, а ПО относительно свежее, поэтому может потенциально быть не стабильным, а сроки никто не продлевал и бюджет не увеличивал. Но с IP-IP должно быть меньше проблем, чем с GRE, так как на используемых fw есть поддержка offload IP-IP туннелей.

Плюсы:

Минусы:

BGP communities

Если б не было тебя BGP, не было бы communities, значит и не было бы этого решения задачи. Это довольно интересное и не сложное решение задачи, но, при этом, сильно зависит от производительности control plane всех устройств и стабильности ПО, а также, в зависимости от количества устройств (масштабирования) экспоненциально увеличивает итоговую конфигурацию в размере.

RT community

Пожалуй, самое логичное и в то же время самое сложное для понимания решение, если с этим не работал ранее, но мы же тут все матерые сетевики, не так ли? Смысл простой, как и всегда - route target extended community (далее community) является в данном сценарии логической “меткой” (не путать с MPLS label), при получении префикса, помеченного которым(и), мы принимаем то или иное действие. В нашем сценарии ассоциируем возможный путь прохождения трафика (конечно это не LSP по ERO..) с уникальным значением community и добавляем данный(ые) community к префиксу.

Например: чтобы не использовать логику на fw, мы просто маркируем префиксы, полученные/сгенерированные на edge, community с определенным значением, за которым скрывается соответствие определенному действию, и отправляем данный префикс с данным community на fw. Поскольку данное community является транзитивным, то fw просто передает префикс с этим community дальше, на spine, не меняя его. На spine настраивается политика маршрутизации, в которой указано что требуется сделать, когда от fw придет префикс с определенным community, (например: изменить next-hop или сбросить префикс). В то же время, если приходит префикс без указанного community, то данный префикс будет сброшен по умолчанию (default reject). В обратном направлении распространение префиксов происходит аналогичным образом, добавляя к префиксу определенный(ые) community, которое(ые) ассоциируется с возможным путем прохождения трафика, по которому будет принято то или иное действие.

Открываем нашу старую целевую в PDF и смотрим детальнее, как это выглядит:

Исходя из логики настройки и работы вышеупомянутой симметричной схемы на control plane, мы получаем возможность увести логику по предотвращению проблемы асимметричного прохождения трафика при аварии на одном линке к fw, от fw на уровни edge и spine.

Если коротко, каким образом предотвращается асимметричное прохождения трафика, например:

На fw и на edge/spine на BGP соседстве с fw, в обязательном порядке должна быть выключена задержка отправки BGP UPDATE Message (eg rapid-withdrawal), это позволит быстрее реагировать при проблемах на не симметричных отказах СПД. В некоторых случаях может понадобится поменять таймеры для процесса BGP и/или его pipeline (eg bgp scan-time). К тому же, следует следить за загрузкой control plane и за состоянием стабильности сети, это напрямую влияет на скорость сходимости сети при высокой нагрузке и горизонтальном масштабировании.

Плюсы:

Минусы:

В данной секции не могу не упомянуть BGP Link Bandwidth Extended Community, которое позволяет прибегнуть к распределению нагрузки по UCMP, используя BW community, которыми можно “помечать” префиксы полученные через single-hop BGP сессии, и тем самым передавать BGP соседям информацию о скорости интерфейса, в следствии чего, можно масштабировать фабрику используя устройства или целые плоскости разной производительности. Раз уж зашли про целые плоскости, то можно передавать вышестоящим и нижестоящим BGP соседям aggregate bandwidth для применения балансировки по UCMP между целыми плоскостями, если вдруг внутри какой-то из плоскостей случится авария.

И поскольку я уже неоднократно говорил про плоскости, ниже схема IPS фабрики с двумя плоскостями.
scale-fabrics
В данной схеме видно, что уровни edge/br leaf заменяются на уровень tfs, который в свою очередь уже подключаются к edge/br leaf коммутаторам. Но почему бы их не подключить сразу к p/spine коммутаторам, как на схеме ниже?
scale-fabrics
Во первых - масштабирование и высокая стоимость интерфейсов spine/p устройств, а во вторых, все по той же причине, связанной с symmetric hashing - flow нужно балансировать теперь еще и по плоскостям, симметрично в оба направления, чтобы не было потери трафика из-за отсутствия синхронизации состояния flow на fw, и чтобы это сделать правильно, вспоминаем условия симметричной балансировки, и делаем вывод, что для агрегации разных плоскостей, нужны еще устройства, удовлетворяющие решению задачи симметричной балансировки.

Конечно, в stateless сети мы могли бы назначить стоимость каждого интерфейса, например, в плоскости 1 равной 100g, а в плоскости 2 равной 40g и после чего передать aggregate bandwidth на edge/br leaf коммутаторы, которые бы уже равномерно разбалансировали трафик по разным плоскостям, а если бы случилась авария на линке или fw внутри какой-либо плоскости, то aggregate bandwidth бы поменялось и поменялось бы распределение трафика по плоскостям. Но, у нас ведь есть stateful устройства на сети, поэтому, есть вероятность, что данное решение не будет применимо. Однако, следует еще протестировать данное решение, ведь есть вероятность, что в зависимости от реализации, в случае аварии, вызывающей изменение aggregate bandwidth, resilient hashing сможет предотвратить перераспределение всего трафика между плоскостями, а для проблемы с асимметричным прохождением трафика нам помогут все те же знакомые действующие лица: транзитивные route target extended community и политики маршрутизации.

Выводы делайте сами, данное решение в stateful сети еще мною не тестировалось, но потенциал у данного решения определенно есть!

Целевая схема одной DPI фабрики

Все же, жизнь не кажется сказкой и исходя из всех предыдущих вариантов, всех проблем, которые могут возникнуть, для решения проблемы асимметричного прохождения трафика при одиночных или двойных отказах, самым очевидным становится следующий вариант, схема которого ниже.
scale-fabric-normalized
Да, логика данного варианта описана в предыдущей секции ‘Link bandwidth community’ и она прекрасно подходит под использование всего одной DPI фабрики.

Какие же особенности в ней есть? Используется все тот же BGP, та же логика с RT communities (только вся логика теперь не на edge/spine, а на tfs, естественно), та же логика с симметричной балансировкой и коммутацией. Но! Добавляется еще один уровень между fw и edge/spine, который на схеме называется tfs. Ключевым является то, что данный уровень может использоваться сразу для решения нескольких задач, он может быть не обязательно умным (а значит будет дешевым), но самое важное, чтобы была поддержка BGP, ECMP с применением симметричной балансировки и vrf-lite подобных механизмов. Этот уровень нужен для того, чтобы можно было “нормализовать” прохождение трафика внутри DPI фабрики в случае одиночного или двойного отказа на линках, при помощи симметричной балансировки. Кроме того, для увеличения скорости сходимости сети, данный уровень может использовать обходные туннели через edge/spine, чего раньше мы не могли себе позволить с leaf коммутаторами.

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

Минусы:

Проблемы

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

Перейдем к разбору некоторых проблем:

Конфигурация

Вот и дошли мы до финального аккорда, который будет самым длинным, но не менее важным! В конкретном примере мы рассмотрим конфигурацию edge, но для spine и tfs коммутаторов конфигурация не будет сильно отличаться

Заключение

С улыбкой и болью вспоминаю фразу из притчи “о доверии (вендорам)” Марата Сибгатулина с linkmeetup: “на интеграционные тесты вендора не полагайся - сам организуй синтетические и продуктивные тесты.”.

На этапе внедрения нас ждали проблемы на каждом из уровней взаимодействия с данной схемой, на разных производителях, разных платформах и моделях:

Исходя из этого, могу сказать следующее:

  1. Что бы тебе не говорил тот или иной производитель, какие-бы заключения самостоятельного тестирования не показывал, всегда могут найтись отклонения в конфигурации, ревизии hardware, в различном software, ошибках в software, в наличии включенных и/или выключенных тех или иных особенностях, которые могут напрямую влиять на исполнение решения поставленной задачи, поэтому, собирать лабораторную среду, даже для синтетических тестов, нужно 1:1, как планируется сделать в продуктивной среде;
  2. И только после самостоятельного тестирования оборудования на нужных паттернах трафика можно с сомнением сказать, будет ли оно работать или нет, и попросить коллег перепроверить за тобой :) ;
  3. А с сомнением, все потому, что, синтетические тесты не отменяют продуктивные и в момент времени продуктивный трафик может отличаться от синтетического, что может напрямую повлиять на оборудование и выполнение поставленной задачи;
  4. Будь готов к проблемам и fallback или изоляции проблемного компонента СПД.

И все же, в итоге, мы получили отказоустойчивую DPI фабрику с возможностью горизонтального масштабирования.

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

Благодарности

Ссылки

Общие подходы к балансировке:

Про hashing:

Про UCMP:

Про дизайн сетей в ДЦ:

Подкаст про все вышеперечисленное по данной заметке:

Tags: juniper qfx mpls bgp evpn l3vpn vxlan dpi ips hash hashing symmetric resilient