CC BY
0
doi: 10.36724/2409-5419-2024-16-3-39-45
РЕАЛИЗАЦИЯ СЕТЕВЫХ ФУНКЦИЙ В IP-ФАБРИКЕ ЦЕНТРА ОБРАБОТКИ ДАННЫХ
БУЖИН
Игорь Геннадьевич1 АНТОНОВА
Вероника Михайловна2 ГНЕЗДИЛОВ
Владислав Станиславович 3
МИРОНОВ Юрий Борисович 4
Сведения об авторах:
1 к.т.н., доцент кафедры "Сети и системы фиксированной связи", Московский Технический Университет Связи и Информатики, Москва, Россия, i.g.buzhin@mtuci.ru
АННОТАЦИЯ
Введение: в современных дата-центрах часто применяют IP-фабрики, которые являются системой объединенных сетевых устройств с высокой степенью взаимосвязи, благодаря чему минимизируется расстояние между конечными узлами, сокращаются задержки, и устройства функционируют более эффективно. При этом многие процедуры переносятся в наложенную (оверлейную) сеть с помощью технологии виртуализации сетевых функций. В связи с этим возникает проблема эффективной реализации сетевых функций в IP-фабрике центра обработки данных. Цель исследования: нахождение эффективного способа реализации виртуализации сетевых функций в IP-фабрике центра обработки данных. Обоснованность данного подхода доказана экспериментально. Данный подход работает для обработки различного типа трафика. Результаты: Предложен подход к реализации сетевых функций в IP-фабрике центра обработки данных. Выбран способ обработки трафика на сервере общего пользования на основе технологии VPP и FRR. Показаны результаты тестовых измерений обработки различного трафика на уровне передачи данных (data plane). Результаты экспериментальных тестов показывают, что на 1 ядре Xeon Cascade Lake технология VPP выдает производительность порядка 20 Mpps при IPv4 трафике. Комбинации обработки IPv4-lookup, VxLAN, Encap/Decap, ACL-lookup показывают более низкую производительность. Предложен способ доставки трафика до сетевых функций IP-фабрики на основе технологий VxLAN, EVPN и ECMP.
2 к.т.н., доцент, зав. кафедры "Сети и системы фиксированной связи", Московский Технический Университет Связи и Информатики, Москва, Россия, v.m.antonova@mtuci.ru
3 ассистент кафедры "Сети и системы фиксированной связи", Московский Технический Университет Связи и Информатики, Москва, Россия, v.s.gnezdilov@mtuci.ru
4 к.т.н., декан факультета "Сети и системы связи", Московский Технический Университет Связи и Информатики, Москва, Россия, i.b.mironov@mtuci.ru
КЛЮЧЕВЫЕ СЛОВА: IP-фабрика, FRR, Виртуализация Сетевых Функций (ВСФ), VPP, VxLAN.
Для цитирования: Бужин И.Г., Антонова В.М., Гнездилов B.C., Миронов Ю.Б. Реализация сетевых функций в IP-фабрике центра обработки данных // Наукоемкие технологии в космических исследованиях Земли. 2024. Т. 16. № 3. С. 39-45. doi: 10.36724/2409-5419-2024-16-3-39-45
Введение
В современных центрах обработки данных используются IP-фабрики - это объединенная система сетевых устройств с высокой степенью взаимосвязи в центре обработки данных, развернутая на двух или трех уровнях. Благодаря этому значительно упрощается сетевая архитектура: минимизируется расстояние ме^ду конечными узлами, сокращаются задержки, и устройства функционируют более эффективно. Многие процедуры, необходимые для организации сетевого взаимодействия, переносятся в оверлейную сеть: сегментация, виртуализация и прочие взаимосвязанные сервисы сдвигаются в наложенную (оверлейную) сеть, функционирующую поверх IP-фабрики. При этом осуществляется поддержка стандартных протоколов динамической маршрутизации.
IP-фабрика - это сетевая архитектура, обеспечивающая высокий уровень связности, резервирования, гарантированную полосу взаимодействия, QoS для сетей с одноранговым обменом. IP-фабрика предоставляет транспортный сервис для различных наложенных (оверлейных) IP-сетей. Эта топология опирается на структуру дерева (fat-tree) и стебля с листьями (spine-leaf) - последняя также известна как «сеть Клоза» и представляет собой многокаскадную коммутационную сеть. Во многих современных центрах обработки данных архитектура сети Клоза реализуется в виде схемы "leaf-spine", где уровень "spine" представляет коммутаторы на магистральном уровне, а уровень "leaf" - пограничные коммутаторы на входе и выходе. Такую схему также иногда называют топологией утолщенного дерева (fat-tree).
Цель данной топологии в уменьшении общего количества требуемых коммутаторов и портов. Архитектура 1Р-фабрики (рис. 1) подразумевает наличие большого количества высокоскоростных прямых каналов связи, которые позволяют избегать замедления скорости в сети, вызванного появлением «бутылочных горлышек», и поддерживать высокую эффективность перенаправления трафика и низкую задержку. Использование такой архитектуры в дата-центре дает ряд преимуществ по сравнению с классической двухуровневой архитектурой со «свернутым» ядром сети (collapsed core):
• увеличивается отказоустойчивость. В сети collapsed core независимых ядер может быть только два - это ограничение технологий агрегации MLAG (Multi-Chassis Link Aggregation), которые позволяют объединять интерфейсы в группы максимум между двумя коммутаторами. Коммутаторов же Spine может быть гораздо больше.
• облегчается увеличение пропускной способности - для этого нужно просто добавить необходимое число коммутаторов Spine.
• сбои затрагивают меньше устройств - коммутаторы полностью независимы, отказоустойчивость достигается без использования стекирования или MLAG.
• задержка становится предсказуемой - на пути любого потока внутреннего трафика находится только один коммутатор Spine.
• повышается уровень утилизации сетевых интерфейсов -трафик между Leaf и Spine прозрачно и эффективно распределяется с помощью механизмов ЕСМР (Equal Cost Multipath).
Однако, при реализации архитектуры IP-фабрики используется сетевое оборудование центров обработки данных, которое не позволяет, в случае необходимости, организовать сервисы по дополнительной обработки трафика - применение функций NAT (трансляции адресов), особая фильтрация трафика L3/L4, применение систем обнаружения и предотвращения вторжений (IPS/IDS), ассиметричная отдача трафика с сервиса (Direct Server Return). При этом при такой реализации IP-фабрики нет возможности модифицировать сетевой стек.
Рис. 1. Архитектура 1Р-фабрики
Таким образом, при организации дополнительных сервисов по обработке трафика на 1Р-фабрике необходимо решить несколько задач: выбрать способ обработки трафика, как организовать доставку трафика до места обработки, как выполнить требования по архитектуре сети (отсутствие возможности модификации сетевого стека) и как обеспечить масштабирование и резервирование.
Способы обработки трафика на сервере общего пользования
Для реализации обработки сетевого трафика на серверах общего пользования применяется подход виртуализации сетевых функций (ОТУ).
В соответствии с эталонной архитектурой №У [8], систему, состоящую из программно-аппаратных средств для реализации МБУ, можно представить из следующих элементов (рис. 2):
• виртуальные сетевые функции (УОТ^в));
• виртуальная сетевая инфраструктура (ОТ1 VI);
• ПО управления и оркестрации №У
Примерами такого функционала могут быть протоколы маршрутизации, трансляция сетевых адресов, реализация списков доступа и межсетевого экранирования, реализация механизмов 0о8 и т.д. Инфраструктура №У представляет собой абстракцию аппаратных средств сетей связи, фактически является набором программных средств для реализации виртуализации аппаратных ресурсов, включая память и вычислительные ресурсы.
Рис. 2. Упрощенная архитектура виртуализации сетевых функций аппаратных средств связи (коммутаторов, маршрутизаторов и т.д.)
Для правильного и скоординированного функционирования инфраструктуры и функций NFV используется оркестратор NFVO. Его главными функциями являются подключение и создание экземпляров VNF и сетевых служб, изменение ресурсов инфраструктуры. Оркестратор постоянно взаимодействует с менеджером VNF, который следит и обеспечивает жизненный цикл всех сетевых функций. Менеджер VIM управляет и контролирует инфраструктурой. Его ключевыми функциями являются идентификация средств инфраструктуры (аппаратные и программные), перераспределение ресурсов между виртуальными сущностями (виртуальными машинами или контейнерами), мониторинг параметров функционирования виртуальных сущностей и их взаимодействий.
Концепция NFV позволяется заменить функции устройств BNG/BRAS - шлюзы-сервера для подключения абонентов в глобальную сеть. В качестве сетевых функций BRAS выступают протоколы установления сессий РРРоЕ, DHCP/IPoE, реализация сервера RADIUS для управления абонентскими сессиями, автоматическое создание VLAN для каждого отдельного сервиса (S-VLAN), реализация протокола GRE для HTTP Redirect сервера, реализация QoS на уровне VLAN. В классическом аппаратном исполнении BRAS имеют высокую стоимость и проприетарные реализации вышеперечисленных функций, которые привязаны к аппаратной части. Инфраструктура NFV позволяет реализовать такой функционал на группе серверов общего пользования с возможностью масштабирования функционала.
Помимо этого, NFV позволяет реализовать без специализированных аппаратных средств DPI - глубокая инспекция пакетов - функция, позволяющая оператору связи ограничивать или определять уровень сервиса (квоту, скорость) для определённого типа приложения или содержимого.
Таким образом, концепция NFV позволяет повысить производительности сети, оптимизировать загрузку ресурсов аппаратных устройств, сократить расходы на приобретение и техническое обслуживание специфических аппаратных и аппаратно-программных телекоммуникационных устройств,
уменьшить энергопотребление сети, а также унифицировать реализацию сетевых функций на аппаратных средствах.
Для реализации данного подхода необходимо выбрать реализацию для уровня передачи данных (data plane) и для уровня управления (control plane). Сервер сетевых функций показан на рисунке 3.
Control plane FRR BGPEVPN
4 Linux netlink >
SYNC-SERVICE
à VPP API >
Data plane VPP (DPDK)
Рис. 3. Сервер сетевых функций
Для обеспечения необходимого уровня производительности Data Plane было выбрана реализация VPP [9] на основе DPDK [10]. Платформа VPP [9] - одна из новейших платформ для высокоскоростной обработки пакетов. Она полностью выполняется в пространстве пользователя и реализует методы обхода ядра для доступа к оборудованию. Ее дизайн не зависит от оборудования, ядра и развертывания. В отличие от старых методов обработки «пакет за пакетом», VPP обрабатывает сразу вектор пакетов. Таким образом, это обработка "вектор за вектором". VPP использует сервисы DPDK [10] для обхода ядра и доступа к аппаратному обеспечению. Пакет DPDK является интегрированной частью пакета VPP. Сетевой ввод-вывод реализован DPDK, а обработка пакетов реализована приложением VPP. VPP использует DPDK для получения вектора пакетов с сетевой карты, а затем обрабатывает все пакеты в векторе. Вектор - это группа пакетов, которые обрабатываются одновременно. Текущий размер вектора равен 256 пакетов.
Как только буфер пакетов (один вектор) становится доступен, VPP начинает обработку всех пакетов в векторе. Обработка VPP реализована в виде графа пересылки. Каждый узел представляет собой сетевую функцию. Существует четыре типа узлов: 1) Предварительный ввод 2) Входной сигнал 3) Внутренний 4) Процесс. Узлы предварительного ввода -это функции, которые обрабатывают выборку пакетов с аппаратного обеспечения и делают буфер индексов доступным для VPP. Узел ввода может находиться в двух состояниях: прерывание или опрос. Входные узлы находятся в режиме прерывания, когда количество пакетов, доступных в буфере, меньше пяти. Когда доступно более 10 пакетов, узел переходит из режима прерывания в режим опроса. В режиме опроса узел непрерывно продолжает проверять, есть ли какие-либо пакеты, доступные для заполнения вектора и обработки.
Узлы процесса - это отдельные узлы, которые не подключены к графу. Они выполняются отдельно как потоки. Каждый узел предсказывает следующий узел после обработки вектора и отправляет пакеты различным следующим узлам на основе своего решения. Это называется предсказанием ветвления.
IPv4 -■ IPv4-VxLAN • IPv4-VxLAN-ACL
0 -
2 4 6 8 10 12 14 16
Cores
Рис. 4. Производительность VPP
Результаты тестов (рис. 4) показывают, что на 1 ядре Xeon Cascade Lake технология VPP выдает производительность порядка 20 Mpps при IPv4 трафике. Комбинации обработки IPv4-lookup, VxLAN, Encap/Decap, ACL-lookup показывают более низкую производительность. Также, из результатов тестов видно, что производительность обработки трафика при добавлении ядер процессора растет нелинейно. Сервер с Intel Xeon 6238 2.2GHz с сетевой картой Intel х710, RAM 512 Gb показал производительность 20 Mpps на 16 ядрах при обработке трафика IPv4-VxLAN-ACL.
В качестве Control plane выбрана открытая реализация BGP - FRR [11]. FRR предоставляет услуги IP-маршрутизации. Его роль в сетевом стеке заключается в обмене информацией о маршрутизации с другими маршрутизаторами, принятии решений о маршрутизации и политике и информировании других уровней об этих решениях. В наиболее распространенном сценарии FRR устанавливает решения о маршрутизации в ядро операционной системы, позволяя сетевому стеку ядра принимать соответствующие решения о переадресации. В дополнение к динамической маршрутизации FRR поддерживает полный спектр конфигураций L3, включая статические маршруты, адреса, рекламные объявления маршрутизаторов и т.д. Он также обладает некоторыми облегченными функциями L2, но это в основном зависит от платформы. Помимо этого, FRR поддерживает EVPN VxLAN и сравнительно легко интегрируется с выбранным Data plane. Для реализации FRR используется программный пакет FRRouting [11], который позволяет реализовать помимо BGP такие протоколы как OSPF, IS-IS, EIGRP, VRRP и т.д. Для конфигурирования используется Cisco-like команды. FRRouting возможно устанавливать и использовать на виртуальных сущностей с NIX системами.
Доставка трафика до сетевых функций 1Р-фабрики
В работе [1] анализируется проблема растущего спроса на виртуализацию ресурсов в центрах обработки данных. Виртуализация аппаратных средств обеспечивает такие преимущества, как более высокая загрузка аппаратных средств (за счет реализации нескольких виртуальных сущностей на аппаратном средстве), уменьшение времени ожидания пользователя, эффективное энергопотребление. Однако сеть передачи данных центров обработки данных также должна поддерживать повышенный спрос на виртуализацию. Согласно [1], этот растущий спрос возможно преодолеть за счет применения NFV, применяя изоляцию трафика, изоляцию адресного пространства (использование одного и того же адресного пространства в изолированных виртуальных сетях).
Для доставки трафика до сетевых функций IP-фабрики используется технология VxLAN [12]. Данная технология разработана для решения проблем масштабируемости VLAN. VxLAN с его 24-разрядным идентификатором сегмента может поддерживать до 16 миллионов виртуальных сетей. VxLAN инкапсулирует фреймы Ethernet в UDP-пакеты, позволяя создавать виртуализированные подсети L2 уровня L3. Таким образом, организуется VxLAN-туннель с коммутатора IP-фабрики непосредственно на сервер сетевых функций.
В данном сценарии нет необходимости перенаправлять трафик на сетевые функции On-Demand (т.е. устанавливать соединения только в случае активности определенного типа трафика), сервисы которым требуется специфическая обработка трафика определены заранее. Группа сервисов определяется одним VRF с доступом в глобальную таблицу через ACL.
Таким образом, VxLAN позволяет делать изоляцию L3. Также для безопасности L2 используется Switched Virtual Interface (SVI) [13] для скрытия МАС-адреса. SVI работает как шлюз по умолчанию. Также для безопасности VxLAN может использовать отельную таблицу VRF для изоляции адресного пространства, что также позволяет использовать одни и те же IP-адреса разными клиентами в разных адресных пространствах.
Для построения overlay предлагается использовать EVPN VXLAN Туре5 IP-PREFIX-ROUTE (RFC9136 [14]), модель IP-VRF-to-IP-VRF, без ESI/GW Overlay Index.
В [2] описывается технология EVPN для уровня управления NFV при использовании в мультитенантных центрах обработки данных. Одной из функций уровня управления NFV является управления потоками трафика ме^ду конечными точками NFV. Для реализации потоков данных трафика необходима плоскость данных, которая реализует переадресацию (маршрутизацию) трафика в сети на основе уровня управления. В [2] рассматривают возможность EVPN для изоляции сетевого трафика для каждого клиента, расширение возможностей подключения на L2 за счет мобильности MAC и возможности масштабирования уровня управления.
EVPN является расширением сообщества Multi Protocol-BGP (MP-BGP) [15], который является новой основой для вычисления достижимости сетевого уровня BGP (NLRI). EVPN NLRI используется расширение MP-BGP под названием Ad-
dress Family Identifier (AFI) и Subsequent Address Family Identifier (SAFI). For EVPN the AFI is 25 (i.e. L2 VPN) and the SAFI is 70 (i.e. EVPN) [4]. В [5] описываются типы маршрутов для EVPN, которые представлены в таблице 1.
Таблица 1
Типы маршрутов EVPN
Для балансировки трафика между серверами сетевых функций (решение проблемы масштабирования и резервирования) используется ЕСМР (Equal-Cost Multi-Path routing) [6]. ЕСМР определяет стоимость (вес) путей до точки доставки, допускает наличие одинаковых путей по весу и может осуществлять балансировку нагрузки трафика между путями с одинаковым весом. Применение ЕСМР для балансировки нагрузки между одинаковыми по стоимости маршрутами повышает эффективность использования сетевых ресурсов, а также отказоустойчивость сети. ЕСМР рекомендуется использовать совместно с EVPN [24].
Так как в центрах обработки данных присутствует большое количество трафика север-юг, то он может быть обслужен (передан по назначению) на основе сопоставления таблицы VRF клиента и таблицы маршрутизации VRF на border leaf switches, которые подключены непосредственно к граничным маршрутизаторам. Border leaf switches помещают информацию о маршрутах в глобальную таблицу маршрутизации для взаимодействия с внешним миром. Помещение информации о маршрутах из VRF клиентов в глобальную таблицу маршрутизации возможно за использования VRF на bor-derleaf switches [7].
Также EVPN допускает многозадачность сегментов Ethernet (ES) (устройство или сеть устройств, подключенные к одному или нескольким каналам связи), в отличии от VxLAN. Полностью активное многозвенное соединение позволяет распределять нагрузку трафика по потокам для эффективного использования каналов. Однако такой режим работы имеет недостаток - могут возникать циклы. Для избегания таких ситуаций в EVPN подход расщепления горизонта, который не допускает обратную отправку пакета, пришедшего по многоадресному соединению. Метка MPLS использует EVPN для фильтрации на основе расщепления горизонта. Когда устройство получает кадр с мультиадресной рассылкой и пытается его переслать, оно проверяет метку, и, в случае совпадения исходящего и входящего интерфейса, кадр не пересылается. Помимо этого, EVPN позволяет выбирать пересыльного таким образом, чтобы трафик многоадресной рассылки можно было отправлять только одному каналу. Это позволяет предотвратить передачу дублированного многоадресного трафика и образования лавинного трафика.
Развертывание EVPN-VxLAN обеспечивает такие преимущества, как наличие архитектуры на основе открытых стандартов, эффективное подключение на L2/L3 на основе
плоскости управления, сегментирование внутренней сети и адресного пространства, мобильность МАС-адресов позволяет эффективно масштабировать и развертывать сеть.
Таким образом, реализация сетевых функций в 1Р-фабрике центра обработки данных может быть представлена как на рисунке 5.
Рис. 5. Архитектура реализации сетевых функций в 1Р-фабрике Заключение
В данной статье осуществлен поиск эффективный способ реализации виртуализации сетевых функций в 1Р-фабрике центра обработки данных. Способ основан на технологиях VPP и FRR. Технология VPP использует сервисы DPDK для обхода ядра и доступа к аппаратному обеспечению.
Проведены экспериментальные измерения обработки различного сетевого трафика с использованием предложенного способа реализации NFV. Результаты экспериментальных тестов показывают, что на 1 ядре Xeon Cascade Lake технология VPP выдает производительность порядка 20 Mpps при IPv4 трафике.
Комбинации обработки IPv4-lookup, VxLAN, En-cap/Decap, ACL-lookup показывают более низкую производительность. Таким образом, обоснованность данного подхода доказана экспериментально. Также предложена архитектура для доставки различного пакетного трафика до сетевых функций IP-фабрики на основе VxLAN. Для построения overlay предлагается использовать EVPN VXLAN Туре5 IP-PREFIX-ROUTE, модель IP-VRF-to-IP-VRF, без ESI/GW Overlay In-
Type Description
RT-1 Ethernet Auto-discovery Route
RT-2 MAC/IP Advertisement Route
RT-3 Inclusive Multicast Ethernet Tag Route
RT-4 Ethernet Segment Route
RT-5 IP Prefix Route
dex. Предложенная архитектура позволяет эффективно обрабатывать трафик в направлении север-юг в центре обработки данных, изолировать адресные пространства и осуществлять балансировку нагрузки по маршрутам с одинаковым весом.
Литература
1. Narten T., Ed., Gray E., Ed., Black D., Fang L., Kreeger L., Na-pierala M. Problem Statement: Overlays for Network Virtualization. RFC 7364. 2014, pp. 1-23. URL: http: //www.hjp.at/doc/rfc/rfc7364.html (дата обращения 23.01. 2024).
2. Sajassi A., Drake J., Bitar N., Shekhar R., Uttaro J., Henderickx W. A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN), tech. rep., IETF, 2018. URL: https://tools.ietf.org/html/rfc8365 (дата обращения 23.01. 2024).
3. Nadeau T., Drake J., Schlisser B., Rekhter Y., Shekhar R., Bitar N., Isaac A., Uttaro J., Hendrix W. A Control Plane forNetwork Virtualized Overlays, tech. rep., IETF, 2012. URL: https://tools.ietf.org/html/draft-drake- nvo3-evpn-control-plane-00 (дата обращения 23.01. 2024).
4. Sajassi A., Aggarwal R., Bitar N., Isaac A., Uttaro J., Drake J., Henderickx W. BGP MPLS-Based Ethernet VPN, RFC 7432 (2015). URL: https://t00ls.ietf.0rg/html/rfc7432#secti0n-7 (дата обращения 23.01.2024).
5. Rabadan E. J., Henderickx W., Drake J., Lin W., Sajassi A. IP Prefix Advertisement in EVPN, tech. rep., IETF, 2018. URL: https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-ll (дата обращения 23.01. 2024).
6. Sajassi A., Aggarwal R., Uttaro J., Bitar N., Henderickx W., Isaac A. Requirements for Ethernet VPN (EVPN), tech. rep., IETF, 2014. URL: https: //tools.ietf.org/html/rfc7209 (датаобращения23.01. 2024).
7. Isaac A. Building blocks in evpn for multi-service fabrics. 2019. URL: https://pc.nanog.org/static/published/meetings/NANOG75/1903/ 20190219_Isaac_Building_Blocks_In_vl.pdf (дата обращения 23.01. 2024).
8. Herrera J.G., Botero J.F. Resource allocation in NFV: A comprehensive survey II IEEE Transactions on Network and Service Management, 2016. Vol. 13. No.3. C. 518-532.
9. Saboori H., Mohammadi M., Taghe R. Virtual power plant (VPP), definition, concept, components and types //2011 Asia-Pacific power and energy engineering conference. IEEE, 2011. c. 1-4.
10. Kourtis M.A. et al. Enhancing VNF performance by exploiting SR-IOV and DPDK packet processing acceleration //2015 IEEE Conference on Network Function Virtualization and Software Defined Network (NFV-SDN). IEEE, 2015. c. 74-78.
11. Jain V., Edgeworth B. Troubleshooting BGP: A practical guide to understanding and troubleshooting BGP. Cisco Press, 2016.
12. Mahalingam M. et al. Virtual extensible local area network (VXLAN): A framework for overlaying virtualized layer 2 networks over layer 3 networks. 2014. No. rfc7348.
13. Sans F. et al. Analytical performance evaluation of different switch solutions II Journal of Computer Networks and Communications. 2013.Vol. 2013.
14. Rabadan J. et al. RFC 9136 IP Prefix Advertisement in Ethernet VPN (EVPN). 2021.
15. PeiD., Van derMerwe J. BGP convergence in virtual private networks II Proceedings of the 6th ACM SIGCOMM Conference on Internet Measurement. 2006. c. 283-288.
16. Hiryanto L. et al. Multi-path routing in green multi-stage upgrade for bundled-links SDN/OSPF-ECMP networks II IEEE Access. 2021. Vol. 9. c. 99073-99091.
17. George D.A.S., George A.S.H. A Brief Overview of VXLAN EVPN II Ijireeice International Journal of Innovative Research in Electrical, Electronics, Instrumentation and Control Engineering. 2021. Vol. 9. No. 7. C. 1-12.
18. Salazar-Chacon G., Marrone L. Open Networking for Modern Data Centers Infrastructures: VXLAN Proof-of-Concept Emulation using LNV and EVPN under Cumulus Linux II2022 IEEE Sixth Ecuador Technical Chapters Meeting (ETCM). IEEE, 2022. c. 1-6.
19. CardonaR. VXLAN BGP EVPN Fabric Configuration Templates II The Fast-Track Guide to VXLAN BGP EVPN Fabrics: Implement Today's Multi-Tenant Software-Defined Networks. Berkeley, CA: Apress, 2021. C. 209-242.
20. Previdi S., Aries E., Afanasiev D. RFC 9087: Segment Routing Centralized BGP Egress Peer Engineering. 2021.
21. Pucci D., Casoni G. Monitoring an EVPN-VxLAN fabric with BGP Monitoring Protocol. 2020.
IMPLEMENTING NETWORK FUNCTIONS IN A DATA CENTER IP FABRIC
IGORG. BUZHIN
Moscow, Russia, i.g.buzhin@mtuci.ru
VERONIKA M. ANTONOVA
Moscow, Russia, v.m.antonova@mtuci.ru
VLADISLAVS. GNEZDILOV
Moscow, Russia, v.s.gnezdilov@mtuci.ru
YURIY B. MIRONOV
Moscow, Russia, i.b.mironov@mtuci.ru
ABSTRACT
Introduction: In modern data centers, IP fabrics are often used, which are a system of interconnected network devices with a high degree of interconnection, thereby minimizing the distance between end nodes, reducing delays, and devices function more efficiently. At the same time, many procedures are transferred to an overlay network using network function virtualization technology. In this regard, there is a problem of effective implementation of network functions in the IP fabric of the data center. The purpose of the study is to find an effective way to implement virtualization of network functions in the IP fabric of a data center. The validity of this approach has been proved experimentally. This approach works to handle different types of traffic.
KEYWORDS: IP fabric, FRR, Network Function Virtualization (NFV), VPP, VxLAN.
Results: An approach to the implementation of network functions in the IP fabric of a data processing center is proposed. The method of processing traffic on a public server based on VPN and FRR technology has been selected. The results of test measurements of processing various traffic on the data plane are shown. The results of experimental tests show that on 1 core of Xeon Cascade Lake, VPP technology produces a performance of about 20 Mpps with IPv4 traffic. Combinations of IPv4 lookup, VxLAN, Encap/Decap, and ACL lookup processing show lower performance. A method for delivering traffic to the network functions of an IP fabric based on VxLAN, EVPN and ECMP technologies is proposed.
REFERENCES
1. T. Narten, E. Gray, D. Black, L. Fang, L. Kreeger, M. Napierala, "Problem Statement: Overlays for Network Virtualization," RFC 7364 2014, pp. 1-23. URL: http: //www.hjp.at/doc/rfc/rfc7364.html (date of access Accessed 23.08. 2019).
2. A. Sajassi, J. Drake, N. Bitar, R. Shekhar, J. Uttaro, W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)," tech. rep., IETF, 2018. URL: https://tools.ietf.org/html/rfc8365.
3. T. Nadeau, J. Drake, B. Schlisser, Y. Rekhter, R. Shekhar, N. Bitar, A. Isaac, J. Uttaro, W. Hendrix, "A Control Plane for Network Virtualized Overlays," tech. rep., IETF, 2012. URL: https://tools.ietf.org/html/draft-drake- nvo3-evpn-control-plane-00.
4. A. Sajassi, R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, "Henderickx W. BGP MPLS-Based Ethernet VPN," RFC 7432. 2015. URL: https://tools.ietf.org/html/rfc7432#section-7 (date of access 4.10.2019).
5. E.J. Rabadan, W. Henderickx, J. Drake, W. Lin, A. Sajassi, "IP Prefix Advertisement in EVPN," tech. rep., IETF, 2018. URL: https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertise-ment-11.
6. A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, A. Isaac, "Requirements for Ethernet VPN (EVPN)," tech. rep., IETF, 2014. URL: https: //tools.ietf.org/html/rfc7209.
7. A. Isaac, "Building blocks in evpn for multi-service fabrics," 2019. URL: https://pc.nanog.org/static/published/meetings/ NAN0G75/1903/20190219_Isaac_Building_Blocks_In_v1.pdf.
8. J.G. Herrera, J.F. Botero, "Resource allocation in NFV: A comprehensive survey," IEEE Transactions on Network and Service Management, 2016. Vol. 13. No.3, pp. 518-532.
9. H. Saboori, M. Mohammadi, R. Taghe, "Virtual power plant (VPP), definition, concept, components and types," 2011 Asia-Pacific power and energy engineering conference. IEEE, 2011, pp. 1-4.
10. M.A. Kourtis et al., "Enhancing VNF performance by exploiting SR-IOV and DPDK packet processing acceleration," 2015 IEEE
Conference on Network Function Virtualization and Software Defined Network (NFV-SDN). IEEE, 2015, pp. 74-78.
11. V. Jain, B. Edgeworth, "Troubleshooting BGP: A practical guide to understanding and troubleshooting BGP," Cisco Press, 2016.
12. M. Mahalingam et al., "Virtual extensible local area network (VXLAN): A framework for overlaying virtualized layer 2 networks over layer 3 networks," 2014. No. rfc7348.
13. F. Sans et al., "Analytical performance evaluation of different switch solutions," Journal of Computer Networks and Communications. 2013. Vol. 2013.
14. J. Rabadan et al., "RFC 9136 IP Prefix Advertisement in Ethernet VPN (EVPN)," 2021.
15. D. Pei, J. Van der Merwe, "BGP convergence in virtual private networks," Proceedings of the 6th ACM SIGCOMM Conference on Internet Measurement. 2006, pp. 283-288.
16. L. Hiryanto et al., "Multi-path routing in green multi-stage upgrade for bundled-links SDN/OSPF-ECMP networks," IEEE Access. 2021. Vol. 9, pp. 99073-99091.
17. D.A.S. George, A.S.H. George, "A Brief Overview of VXLAN EVPN," Ijireeice International Journal of Innovative Research in Electrical, Electronics, Instrumentation and Control Engineering. 2021. Vol. 9. No. 7, pp. 1-12.
18. G. Salazar-Chacon, L. Marrone, "Open Networking for Modern Data Centers Infrastructures: VXLAN Proof-of-Concept Emulation using LNV and EVPN under Cumulus Linux," 2022 IEEE Sixth Ecuador Technical Chapters Meeting (ETCM). IEEE, 2022, pp. 1-6.
19. R. Cardona, "VXLAN BGP EVPN Fabric Configuration Templates," The Fast-Track Guide to VXLAN BGP EVPN Fabrics: Implement Today's Multi-Tenant Software-Defined Networks. Berkeley, CA: Apress, 2021, pp. 209-242.
20. S. Previdi, E. Aries, D. Afanasiev, "RFC 9087: Segment Routing Centralized BGP Egress Peer Engineering," 2021.
21. D. Pucci, G. Casoni, "Monitoring an EVPN-VxLAN fabric with BGP Monitoring Protocol," 2020.
INFORMATION ABOUT AUTHORS:
Igor G. Buzhin, PhD, Associate Professor of the Department "Fixed-line networks and Systems", Moscow Technical University of Communications and Informatics, Moscow, Russia
Veronika M. Antonova, PhD, docent, Head of the Department "Fixed-line networks and Systems", Moscow Technical University of Communications and Informatics, Moscow, Russia
Vladislav S. Gnezdilov, assistant of the Department "Fixed-line networks and Systems", Moscow Technical University of Communications and Informatics, Moscow, Russia
Yuriy B. Mironov, PhD, Dean of the Faculty of "Networks and Communication Systems", Moscow Technical University of Communications and Informatics, Moscow, Russia
For citation: Buzhin I.G., Antonova V.M., Gnezdilov V.S., Mironov Yu.B. Implementing network functions in a data center IP fabric. H&ES Reserch. 2024. Vol. 16. No 3. P. 39-45 doi: 10.36724/2409-5419-2024-16-3-39-45 (In Rus)
