vxlan протокол что это
Виртуальные сети: VXLAN и VMware NSX
Созданные почти четверть века назад виртуальные локальные сети VLAN были для своего времени неплохим способом управления узлами сети. Но в условиях массового перехода на облачные технологии и повсеместным внедрением виртуальных машин возможностей традиционных VLAN для современных ЦОД стало явно недостаточно. Причем самыми болезненными вопросами стало ограничение доменов второго уровня на четырех тысячах VLAN при невозможности переноса виртуальных машин через границы L2.
В рамках стандартной модели сети решение было сравнительно очевидным: сеть надо тоже виртуализировать, создавая виртуальные оверлейные сети поверх существующих.
И как это делается?
На текущий момент существует три распространенных протокола построения оверлейных сетей: VXLAN, NVGRE и STT. Эти три протокола весьма схожи в общем принципе: все они подразумевают существование виртуального коммутатора на базе гипервизора и терминирование туннелей в виртуальных узлах. В итоге на базе этих технологией становится возможным построение логических L2-сетей в рамках уже существующих L3-сетей. Различие между протоколами состоит, в основном, в методах инкапсуляции трафика. Ну и еще в том, что VXLAN продвигается VMware, за NVGRE стоит Microsoft, а STT поддерживается Nicira. Мы не будем говорить, о том, какой протокол лучше, а какой хуже, заметим лишь, что на текущий момент явно лучшей поддержкой со стороны производителей сетевого оборудования обладают стандарты VXLAN и NVGRE, довольно часто попадающие в строчки о поддерживаемых стандартах парой.
В дальнейшем мы будем говорить о VXLAN, но большая часть применима и к остальным стандартам в силу их схожести.
Начнем с главного — с чисел, тем более, что именно количественные ограничения обычных VLAN послужили поводов для создания им замены. В этом плане новая технология значительно расширяет возможности сетей. Для идентификации виртуальной машины в VXLAN-сетях используется два параметра: MAC-адрес машины и VNI — VXLAN Network Identifier. Последний имеет 24-битный формат, что повышает количество возможных виртуальных сетей до 16 миллионов, так что на ближайшее время вопрос количества возможных виртуальных сетей вроде как решен.
На что похожи виртуальные сети?
В рамках концепции OpenStack вся система виртуализации выглядит следующим образом:
Концепция Open Stack
Здесь компонент Nova, являющийся контроллером вычислительных ресурсов, как только дело заходит о создании сети, передает управление на плагин Neutron, который, в свою очередь, уже и занимается созданием виртуальных свитчей, организацией пространства имен и дальнейшим управлением сетью.
Первоначально виртуальный свитч на гипервизоре на самом деле не являлся коммутатором или вообще сетевым устройством. Корректнее всего его можно описать как программно управляемую контрольную панель, которая позволяет подключать сетевые порты виртуальных серверов (vNIC) к реальным физическим портам. Но ведь мы можем соединить их виртуальными туннелями на основе VXLAN и получить… да, удобную управляемую виртуальную сетевую структуру, обеспечивающую взаимодействие виртуальных же серверов.
В итоге выглядит все это примерно так:
Организация туннелей
за предоставленные картинки благодарим неплохую английскую статью
В целом, все выглядит весьма эстетично, а если к этому добавить еще и какое-нибудь облачное хранение данных, то можно не только перенасытить свою речь словом «виртуальный», но и сказать, что датацентр соответствует современной концепции Software Defined Data Center (SDDC).
Осталось определиться с тем, кто и как будет организовывать сеть из виртуальных туннелей.
Одним из вариантов построения такой структуры является решение VMware NSX, представленное осенью 2013 года.
Конечно, вся эта многоуровневая красота вызывает очевидный вопрос: насколько велико пенальти по производительности, вызываемое инкапсуляцией трафика. И тут все упирается в 2 пункта: поддержку VXLAN на уровне коммутационной матрицы и качество программной реализации интеграции виртуальной сети (в случае NSX — это работа службы NSXd и протокола OVSDB).
Наши постоянные читатели наверняка догадались к чему мы клоним: все верно, открытые сетевые операционные системы типа Cumulus на коммутаторах без ОС имеют здесь существенные бонусы за счет выбора хардварной платформы (матрицы Broadcom) и гибкости на уровне построения программной части.
Интеграция NSX и Cumulus
Такая схема организации взаимодействия и совместная разработка программной части в плотном сотрудничестве с VMware позволило Cumulus создать виртуальное решение, работающее с минимальным пенальти:
Вторым явным достоинством становятся широкие возможности по контролю. Судите сами:
Возможности по контролю
Что такое EVPN/VXLAN
В этой статье я расскажу — что такое EVPN/VXLAN и почему особенности этой технологии кажутся мне привлекательными для применения в ЦОД. Я не буду глубоко погружать вас в технические детали, а остановлюсь на них лишь в той мере, в которой это необходимо для знакомства с технологией. Почти все чего я буду касаться в этой статье так или иначе связанно с передачей трафика второго уровня OSI между устройствами в одном широковещательном домене. Есть множество задач прикладного характера, которые можно комфортно решить, имея такую возможность, одним из наиболее знакомых примеров такой задачи является миграция виртуальных машин в рамках одного или нескольких ЦОД. И если некоторое время назад разговор об этом неминуемо поворачивал в плоскость обсуждения проблем и неудобств общего широковещательного домена, сейчас, напротив, мы можем размышлять о решении этой задачи с точки зрения новых возможностей, перспектив и удобства.
Индустрия ЦОД характеризуется особенно высокой плотностью приложений, помноженной на ожидания потребителей, поэтому выбор архитектуры сетевой подсистемы является особенно важным. В беседах с заказчиками я обычно предлагаю трансформировать абстрактные величины характеристик функционирования сетевой подсистемы в область оценки влияния этих величин на бизнес задачи клиента и рисков возникновения того или иного события в жизненном цикле сетевой подсистемы. Это дает возможность рассмотреть знакомые величины с точки зрения предметной области заказчика, например, абстрактные 2 секунды сброса пакетов во время перестроения топологии, свитчовера или регламентных действий могут превратиться во вполне осязаемые 2.5 Гигабайта потерянных данных на каждом 10G порту. Нынешние тенденции уплотнения сервисов и повышения скорости портов актуализируют проблему надежности и стабильности, так как цена секунды простоя в пересчете на бизнес метрики кратно увеличивается в соответствии со ступеньками скоростей 1G-10G-25G-40G-100G.
В традиционной сети второго уровня OSI с множественными путями между коммутаторами мы обязаны использовать STP, MLAG или стекирование. Я кратко опишу индивидуальные особенности этих технологий чтобы стали понятны предпосылки появления новой архитектуры сетевой подсистемы ЦОД. STP сокращает эффективную пропускную способность, просто отключая порты. К этой технологии также есть большие претензии с точки зрения времени сходимости. У STP есть другие минусы, многие знают о них не хуже меня, поэтому любой из реализаций STP ни под каким предлогом не место в ЦОД.
С точки зрения рассмотрения перспектив развития к MLAG, в качестве ядра ЦОД, возникает много вопросов. Нужно четко понимать тот факт, что топология MLAG по определению не может содержать более двух коммутаторов агрегации, и, по-хорошему, требует наличия горизонтальной связи удвоенной емкости между ними. В связи с отсутствием возможности сегментирования и управления трафиком внутри и между шасси применение этой технологии в территориально распределенной среде может быть затруднительным. А определение ресурсов, необходимых для предотвращения события «Dual Master», с помощью предметного анализа сценариев отказа, может чрезвычайно перегрузить решение с точки зрения аппаратной составляющей. Несмотря на то, что коммутаторы агрегации MLAG продолжают функционировать раздельно, они чрезвычайно тесно связаны с точки зрения физической топологии, поэтому пристальное рассмотрение деталей функционирования иногда делает технологию не такой уж привлекательной.
Эксплуатация стека в качестве ядра ЦОД сопряжено с рисками нахождения всех яиц в одной корзине, так как, несмотря на привлекательность и кажущуюся простоту общего Control Plane per Stack, ошибки в программном обеспечении имеют место быть, и вы не застрахованы от их появления именно в вашем случае. Хуже то, что ошибка обычно не может быть локализована в Fault Domain приемлемого размера, стек это не только один большой коммутатор, но и один большой Fault Domain. Тот факт, что возможности стека зачастую ограничены самым слабым компонентом, так как по определению многие таблицы коммутационных чипов должны быть идентичными на всех устройствах, тоже не стоит упускать из вида. К стеку, функционирующему, в распределенной среде возникают тот же набор вопросов отказоустойчивости, которые кратко описаны выше для случая применения MLAG. Кольцевая топология, которой ограничиваются некоторые производители стекируемых коммутаторов, характеризуется потенциально более перегруженными стек портами ближе к границе. В зависимости от профиля вашего трафика это может оказаться проблемой, на которую так же нужно обратить внимание с точки зрения расчета фактической переподписки.
Термин VXLAN обозначает виртуальную расширяемую локальную сеть, и вы можете найти много сходств и думать о VXLAN так же как о VLAN. Но различие в том, что VXLAN это туннель (одностороннее виртуальное соединение между двумя коммутаторами), если говорить более точно это инкапсуляция Ethernet over UDP.
Привычная передача трафика второго уровня между хостами происходит на основе информации о расположении MAC адресов, таблицу которых хранят промежуточные коммутаторы, они обновляют свои знания о сети с помощью механизма слепого обучение по факту прохождения трафика. В мире VXLAN, многое меняется, так, например, для передачи трафика второго уровня промежуточные коммутаторы вовсе не обязаны работать на втором уровне в рамках одного широковещательного домена. Туннелирование Ethernet трафика позволяет транзитным коммутаторам абстрагироваться от понятия MAC адресов, и выполнять свои функции в рамках IP фабрики свободной топологии по правилам маршрутизации. Каждый коммутаторы в ЦОД работают абсолютно независимо от своих соседей, это напоминает распределенную работу сети Интернет, так как регламентные работы на каждом устройстве имеют строго локальный характер. Гибкая физическая топология позволяет четко подстраиваться под профиль трафика в конкретно взятом ЦОД, а свободный выбор типов и количества соединительных портов позволяет строить сети с заданным уровнем переподписки, вплоть до полностью неблокируемых.
Когда трафик от хоста А к хосту B попадает на пограничный коммутатор в виде кадра второго уровня, этот кадр упаковывается внутрь IP пакета и отправляется по IP сети к пограничному коммутатору другой стороны чтобы там произошла процедура распаковки. Началом эпохи разделение компонентов сети на транспортную и сервисную составляющие принято считать внедрение BGP Free Core на базе технологий MPLS в сетях операторов связи. Применительно к ЦОД эта тенденция материализовалась относительно недавно в качестве метода решения задач масштабируемости и упрощения эксплуатации, компоненты такой архитектуры обычно называют Underlay — транспортная сеть, и Overlay – сервисная или виртуальная. Более детально архитектура Network Virtualization Overlays описана в документах [1, 2]. Разделение функций сетевой подсистемы ЦОД, позволяет конфигурировать сервисы отдельно от конфигурации транспортной составляющей. Вы больше не обязаны определять Vlan на каждом транзитном коммутаторе по цепочке, вместо этого вы описываете Overlay сети путем настройки сервиса только там, где он фактически предоставляется, при этом обмен трафиком Overlay сетей в рамках сервиса осуществляется через туннели на базе Underlay сети. С другой стороны, вполне ожидаемым является тот факт, что проведение таких активностей на Underlay сети как изменение физической топологии, добавление/удаление коммутаторов или каналов связи, будет иметь нулевое влияние на конфигурацию сервисной составляющей. Ядро или транспортная составляющая сети ЦОД при этом свободны от обработки и хранения состояний сервисов, табличное пространство коммутационных чипов коммутаторов ядра используется исключительно в рамках задачи построения связности, передачи трафика и обеспечения быстрой сходимости, а информация о состояниях сервисной составляющей присутствует только на границе сети ЦОД.
Примерно в это же время крупные операторы связи и ведущие производители сетевого оборудования заканчивали разработку нового стандарта передачи трафика второго уровня на базе MPLS сетей. К технологии VPLS накопилась критическая масса неудовлетворенных требований в таких задачах как:
Чуть позже было предложено адаптировать операторскую модель EVPN на базе MPLS к применению в IP сетях ЦОДов. Для этого потребовалось согласовать некоторые процедуры стандарта с особенностями VXLAN инкапсуляции и парадигме hop-by-hop маршрутизации, а также несколько дополнить таксономию типов PE устройств — MPLS реализация подразумевает поддержку функций маршрутизации виртуальных сетей всеми PE, а в VXLAN реализации появляется упрощенный тип PE только для коммутации внутри виртуальной сети [4].
VXLAN и EVPN являются стандартами [5, 6] и вы можете надеяться на согласованную работу в мультивендорной сети [7]. Первый стандарт интересен тем что описывает детали инкапсуляции Ethernet трафика, он относится к тем вещам, которые мы видим «на проводе». Второй стандарт намного более объемный, там описаны правила обмена информацией о MAC адресах как об IP префиксах и предложена модель поддержки множественных тенантов или сервисов на базе общей сети. Для всего этого не стали придумывать отдельный протокол, авторы решили дополнить BGP новыми сущностями. Итак, если говорить просто — VXLAN это инкапсуляция на проводе или data-plane, EVPN — это набор правил, руководствуясь которыми коммутаторы передают трафик второго уровня поверх IP сети, т. е. control-plane.
Имея в своем распоряжении только VLAN теги, вы можете оперировать количеством сервисов или сегментов ограниченным сверху 12-ти битным числом, т. е. 4096. В VXLAN для идентификации сегментов отводится уже 24 бита, т. е. предельное количество экземпляров VNI (это аналог VLAN тега) равно 16-ти миллионам. Не думайте о первом числе как о чем-то недостижимом, а о втором как о бесполезно большом, в сети ЦОД с множественными сервисами оценка величины требуемых сегментов вполне может приблизиться к верхнему пределу количества VLAN. Сравнение с точки зрения этой количественной характеристики напоминает IPv4 против IPv6.
EVPN/VXLAN поддерживает передачу трафика второго уровня по множественным путям (ECMP передача). Если вспомнить что VXLAN это туннель, станет понятно, что это свойство наследуется совершенно естественным образом. Достаточно указать точку назначения туннеля в IP заголовке внешнего пакета, и у транзитных коммутаторов появляется возможность утилизировать потоками трафика все возможные пути. Инкапсуляция VXLAN специально разработана таким образом чтобы передача потока с соблюдением последовательности пакетов не требовала серьезной инспекция транзитного пакета. Для этой цели используется заголовок транспортного уровня, полем повышения энтропии трафика и идентификатором потока служит номер UDP порта. Заполнение этого поля выполняется на пограничных коммутаторах, так чтобы транзитным коммутаторам не приходилось глубоко заглядывать в содержимое пакета, что снижает требования к их коммутационным чипам. Это означает что вы можете строить высокопроизводительные IP фабрики используя коммутаторы общего назначения.
Я уже писал, как использование Overlay сетей влияет на масштабируемость ядра сетевой подсистемы ЦОД, давайте рассмотрим еще один аспект этого понятия – снижение уровня широковещательного трафика. Этот вопрос в функционале EVPN рождает больше всего недопонимания, но на самом деле все просто. Коммутаторы EVPN используют программный метод обучения MAC адресов на базе обмена BGP сообщениями, после появления нового MAC адреса на порту доступа выполняется синхронизация таблиц коммутации по всей сети. К моменту начала передачи трафика включившегося сервера, таблицы коммутации уже содержат актуальную информацию, поэтому у удаленной стороны нет необходимости реплицировать кадр с unknown unicast адресом назначения на все порты доступа ЦОД. Это существенное отличие от классического метода «слепого» наполнения таблиц по факту поступления трафика, не только оптимизирует полосу на каналах связи и портах доступа ЦОД, но и снижает накладные расходы на обработку фреймов второго уровня серверами, которые не должны являться их получателями.
Программное обучение MAC адресам делает их более мобильными, в стандарте предусмотрены, лишенные недостатков широковещательной репликации, процедуры подготовки таблиц коммутации для случая перемещения MAC адреса с одного порта доступа на другой, как это обычно происходит в момент горячей миграции виртуальной машины.
Вопросы времени сходимости и реакции на изменение топологии необходимо рассматривать в компонентах Overlay и Underlay по отдельности. Что касается Underlay сети, старайтесь придерживаться общепринятых практик построения маршрутизируемых сетей, применительно к IP фабрике они выражаются несколькими простыми рекомендациями:
При отказе или отключении порта, коммутатор сигнализирует об аварии используя сообщение отключения от Ethernet сегмента, таким образом удаленные коммутаторы могут обновить таблицу коммутации, не дожидаясь генерации и обработки набора сообщений об отключении всех MAC адресов по отдельности.
Предыдущие текст по большей части касался передачи трафика второго уровня OSI, это далеко не единственная область применения EVPN, сейчас я расскажу почему об этой технологии говорят, как о методе интеграции маршрутизации и коммутации. Давайте подумаем, что мешает присутствию двух или более маршрутизаторов в одном сегменте сети второго уровня. Ответов может быть много, но один из них звучит примерно так — потому-то на втором уровне OSI нет возможности передавать трафик по множественным путям. Коммутатору нужно точно знать в какой порт отправлять трафик к MAC адресу маршрутизатора по умолчанию, так как этот адрес в классической Ethernet сети не может быть активным на разных портах одновременно. Но, как мы увидели раньше, разработчики EVPN реализовали Active-Active передачу трафика на базе программного метода распространения MAC информации, поэтому два или более двух коммутаторов могут объявить своим EVPN соседям о локальном присутствии MAC адреса маршрутизатора по умолчанию в рамках VXLAN сети. Маршрутизация между сетями может осуществляться в Active-Active режиме на множестве коммутаторов, объявивших себя маршрутизаторами по умолчанию. Эти устройства ведут себя как распределенный маршрутизатор, каждая часть которого имеет один и тот же IP и MAC адреса или Anycast Gateway, т.е. проблема превращается в преимущество. EVPN предусматривает механизмы обмена не только MAC, но и IP информацией, поэтому табличные данные и поведение распределенного маршрутизатора будет идентично на всех его компонентах.
Применительно к симметричной топологии ЦОД маршрутизацию обычно реализуют в одном из четырех вариантах:
С другой стороны, маршрутизация на Leaf уровне выглядит более привлекательно с точки зрения общего времени передачи и утилизации портов, но симметричное подключение таких блоков сетевой подсистемы ЦОД как сервисный и пограничный, может вызвать неоправданные сложности. Поэтому часто выделяют так называемую сервисную стойку или стойки, Leaf коммутаторы в которых целиком и полностью работают мостиком между Overlay сетью и остальными блоками сетевой подсистемы ЦОД. При этому значительно снижаются ожидания к коммутаторам Spine уровня, по сути от них требуется только передача IP трафика, но на практике обычно эти коммутаторы так же выполняют функцию отражателей маршрутов BGP-RR.
Технически говоря, трафик между VXLAN сетями можно маршрутизировать и вне Overlay домена, классический IP маршрутизатор вполне может быть подключен к порту доступа EVPN/VXLAN сети в качестве клиента. Но этот метод лишен таких полезных качеств как Active-Active передача к Anycast-Gateway и не удовлетворяет требованиям резервирования, поэтому на практике используется только как промежуточный этап, в качестве метода плавной миграции транспортной компоненты сети ЦОД с Ethernet к EVPN/VXLAN.
[1] RFC7364 «Problem Statement: Overlays for Network Virtualization»
[2] RFC7365 «Framework for Data Center (DC) Network Virtualization»
[3] RFC7209 «Requirements for Ethernet VPN (EVPN)»
[4] draft-ietf-bess-evpn-overlay «A Network Virtualization Overlay Solution using EVPN»
[5] RFC7348 «Virtual eXtensible Local Area Network (VXLAN): A Frameworkfor Overlaying Virtualized Layer 2 Networks over Layer 3 Networks»
[6] RFC7432 «BGP MPLS-Based Ethernet VPN»
[7] EANTC «Multi-Vendor Interoperability Test», 2017
[8] draft-ietf-bess-service-chaining-03 «Service Chaining using Virtual Networks with BGP VPNs»
Русские Блоги
Подробное объяснение и практика VXLAN
Подробное объяснение и практика VXLAN
Зачем вам нужен VXLAN
Введение в принцип работы протокола VXLAN
По сравнению с преобразованием традиционной сети уровня 2 или уровня 3, туннельная сеть VXLAN оказывает меньшее влияние на исходную сетевую архитектуру. Туннельная сеть не требует каких-либо изменений исходной сети, и новая сеть может быть построена на основе исходной сети.
VXLAN была создана в исходной IP-сети, если это сеть, доступная для трехуровневой сети (может связываться друг с другом через IP), VXLAN может быть развернута. В каждой точке останова в сети VXLAN имеется устройство VTEP, которое отвечает за инкапсуляцию и распаковку сообщений протокола VXLAN, то есть за инкапсуляцию заголовка связи VTEP в виртуальном сообщении. В физической сети можно создать несколько сетей VXLAN, которые можно рассматривать как туннель, и виртуальные машины / контейнеры на разных узлах могут напрямую подключаться через туннель. Различные сети VXLAN идентифицируются с помощью VNI, поэтому разные сети VXLAN могут быть изолированы друг от друга.
Несколько важных концепций VXLAN
Необходимая информация для сети VXLAN
Процесс пересылки сообщения VXLAN следующий: исходное сообщение Jin Guo VTEP добавляется ядром Linux с заголовком VXLAN и внешним заголовком UDP, а затем отправляется. После получения пакета VXLAN противоположный конец удаляет заголовок UDP и отправляет пакет на сервер назначения в соответствии с VNI в заголовке VXLAN.
Приведенная выше информация не кажется сложной, но при первом общении необходимо решить следующие проблемы:
Первый вопрос: VTEP обычно назначают сетевые администраторы. Два других вопроса можно свести к одному вопросу: как две стороны в сети VXLAN воспринимают друг друга и выбирают правильный путь для передачи пакетов? Чтобы ответить на эти два вопроса, нам нужно вернуться к сообщению VXLAN и посмотреть, какая информация требуется для полного сообщения VXLAN:
Подводя итог: сообщению VXLAN необходимо знать две адресные данные: MAC-адрес внутреннего сообщения (виртуальная машина / контейнер назначения) и IP-адрес внешнего сообщения (VTEP хоста, на котором находится виртуальная машина / контейнер назначения. расположенный). Если VNI также динамически осведомлен, то VXLAN необходимо знать три части информации: внутренний MAC, IP-адрес VTEP и VNI.
Обычно есть два способа получить указанную выше информацию: многоадресная рассылка и центр управления. Благодарность многоадресной рассылки заключается в том, что VTEP одной сети VXLAN присоединяются к одной и той же многоадресной сети. Если указанная выше информация необходима, отправьте многоадресную рассылку в группу для запроса. Центр управления сохраняет всю информацию над виртуальной машиной в одном месте и автоматически сообщает VTEP необходимую информацию.
Команды базовой конфигурации VXLAN
Создать интерфейс VXLAN
Эта команда может создать новый интерфейс VXLAN с именем vxlan0, который для связи использует группу многоадресной рассылки 239.1.1.1, которая повреждена eth0. Во время инициализации нет таблицы пересылки, а порт назначения использует 4789, указанный IANA. Обычно интерфейс VXLAN (vxlan0 в примере) называется VTEP, и пакеты подсети VXLAN должны выходить из VTEP.
Удалить интерфейс VXLAN
Просмотр информации об интерфейсе VXLAN
Таблица пересылки VXLAN
Вы можете использовать команду bridge для создания, удаления или просмотра таблицы пересылки интерфейса VXLAN.
Создайте запись для пересылки
Просмотр таблицы переадресации VXLAN
Примечание. Сетевые устройства идентифицируются по их уникальным MAC-адресам, и коммутатор должен знать, какой порт подключен к какому устройству, чтобы обеспечить связь между устройствами. Следовательно, для пересылки уровня 2 требуется таблица, соответствующая MAC-адресам и номерам портов. реализован внутри переключателя. Эта таблица называется таблицей FDB, которая в основном состоит из такой информации, как MAC-адрес, номер VLAN, номер порта и некоторые поля флагов. Если MAC-адрес получателя полученного фрейма данных отсутствует в таблице FDB, данные будут перенаправлены на все порты в VLAN, к которой принадлежат данные, за исключением порта источника. Процесс отправки данных на все другие порты называется затопление. поддон.
Сформирована таблица FDB.Когда коммутатор получает кадр данных, он извлекает MAC-адрес источника, VLAN и порт, получивший кадр данных из кадра данных, чтобы сформировать запись в таблице FDB. Когда в следующий раз вы увидите ту же VLAN. Пакеты с одинаковым MAC-адресом напрямую выбрасываются из порта записи.
Сетевая практика VXLAN
1. Двухточечный VXLAN
Начнем с простой сети VXLAN точка-точка. Двухточечная VXLAN означает, что две машины образуют сеть VXLAN, каждая машина имеет VTEP, а VTEP связываются друг с другом, используя свои IP-адреса.
Сначала создайте интерфейс VXLAN с помощью команд
Команда создаст сетевой интерфейс с именем vxlan0 и типом vxlan. Поясняются некоторые важные параметры:
id 42: укажите значение VNI от 1 до 2 до 24-й степени.
dstport: порт связи VTEP, 4789 выделен IANA и 8472 используется Linux по умолчанию.
remote 192.168.30.108: адрес противоположного VTEP
local 192.168.30.104: IP-адрес, который будет использоваться текущим узлом VTEP, то есть IP-адрес текущего порта туннеля.
dev ens33: текущий узел используется в качестве IP-адреса VTEP для получения IP-адреса VTEP. Обратите внимание, что это имеет то же значение, что и параметр local, вы можете выбрать один из двух во время использования
Настройте IP-адрес для сетевой карты VXLAN и включите
После успешного выполнения вы обнаружите, что таблица маршрутизации имеет следующее содержимое. Все пакеты, адрес назначения которых является сегментом сети 172.17.1.0/24, следует пересылать через vxlan0.
В то же время содержимое записи таблицы fdb vxlan0 выглядит следующим образом
В то же время, используя tcpdump для захвата пакетов, вы можете видеть, что используются пакеты VXLAN.
2. VXLAN в многоадресном режиме
Чтобы сформировать одну и ту же сеть VXLAN, VTEP должны иметь возможность воспринимать существование друг друга.Функция самой группы многоадресной рассылки состоит в формировании виртуальной группы из определенных узлов в сети, поэтому естественно, что VXLAN изначально думала об использовании многоадресной рассылки. осознать это.
Примечание. Если VXLAN хочет использовать многоадресную рассылку, соответствующая сетевая структура должна поддерживать функцию многоадресной рассылки.
Этот эксперимент похож на предыдущий, за исключением того, что хосты не являются соединениями точка-точка, а образуют виртуальное целое посредством многоадресной рассылки.
Хотя добавляется группа многоадресной рассылки, на самом деле это относительно просто. По сравнению с двухточечной передачей, существует больше групп параметров.
Также настройте адрес для интерфейса VXLAN, созданного Kong, и включите его.
239.255.255.255
После выполнения указанной выше команды также будет добавлена информация о маршрутизации.
Разница в содержимом записи таблицы fdb
Поле dst становится многоадресным адресом 239.1.1.1 вместо адреса VTEP предыдущего контрагента, что означает, что после того, как исходное сообщение проходит через vxlan0, оно добавляется ядром в заголовок VXLAN, а IP-адрес внешнего UDP заголовок будет изменен на адрес многоадресной рассылки 239.1.1.1.
Точно так же необходимо настроить узлы связи, чтобы проверить, обмениваются ли они друг с другом через сеть 172.17.1.0/24.
Захват пакетов через tcpdump
Анализируйте коммуникационный процесс в многоадресном режиме
Подведем итог описанному выше процессу: сообщение проверки связи сети VXLAN должно пройти два процесса: адресация ARP + ответ ICMP. Когда устройство VTEP узнает адрес ARP другой стороны, оно исключает процесс адресации ARP.
3. VXLAN + мостовая сеть
Предыдущий метод может реализовать построение оверлейной сети для автоматических разговоров посредством многоадресной рассылки, но между взаимодействующими сторонами существует только один VTEP. В реальной среде каждый хост имеет десятки или даже сотни виртуальных машин или контейнеров, которые должны обмениваться данными, Итак, метод их организации и последующей пересылки через VTEP.
Мы знаем, что мост Linux может подключать несколько сетевых карт, поэтому вы можете использовать мост для размещения нескольких виртуальных машин или контейнеров в одной сети VXLAN. По сравнению с предыдущей многоадресной рассылкой, только дополнительная мост используется для соединения пары veth разных контейнеров на одном и том же хосте. Здесь пространство имен сети используется для замены контейнера. На самом деле принцип тот же. Создайте сетевое пространство имен и подключите сетевую карту eth0 в пространстве имен к мосту через пару veth, и в то же время VXLAN также подключится к мосту.
Сначала создайте VXLAN, используйте режим многоадресной рассылки
Затем создайте мост bridge1, привяжите к нему vxlan0 и включите их
Создайте пространство имен сети и пару пар veth и привяжите один конец пары veth к мосту, а другой конец поместите в пространство имен сети и привяжите IP-адрес 172.17.30.2
Таким же образом настройте сеть VXLAN на хосте Lingtai с 172.17.30.3/24 на eth0 в другом пространстве имен сети Li Ge.
Начиная с 172.17.30.2 Ping 172.17.30.3 Весь процесс аналогичен предыдущей реализации, за исключением того, что сообщение ARP, отправленное контейнером, сначала проходит через мост, а затем перенаправляется на vxlan0; а затем Linux на vxlan0. Ядро добавляет заголовок VXLAN. Запросите MAC-адрес узла связи через многоадресную рассылку.
Логически сетевые карты в пространстве имен сети на разных хостах в сети VXLAN подключены к одному мосту.
4. Распределенный центр управления
Поскольку не все сетевые устройства поддерживают многоадресную рассылку и потери сообщений, вызванные методом многоадресной рассылки, режим многоадресной рассылки VXLAN редко используется в реальной производственной среде.
Вспомните, почему мы используем многоадресную рассылку. Из процесса многоадресной рассылки видно, что наиболее важным для туннельной сети для отправки пакетов является знание MAC-адреса виртуальной машины / контейнера другой стороны и IP-адреса VTEP узла, на котором он расположен. Для оверлейной сети диапазон ее сетевых сегментов распределяется по нескольким хостам, поэтому широковещательную передачу традиционных сообщений ARP нельзя использовать напрямую. Если вы хотите транслировать в оверлейной сети, вам необходимо отправить сообщение на все узлы VTEP, которые используют многоадресную рассылку. Если MAC-адрес и информация об IP-адресе VTEP известны заранее, а VETP отправителя отправляется напрямую, в многоадресной рассылке нет необходимости.
В сценарии виртуальной машины и контейнера, когда виртуальная машина или контейнер все еще обменивается данными, мы можем знать ее IP-адрес и Mac (могут быть получены каким-либо образом или могут контролироваться заранее Эти два адреса) распределенный центр управления сохраняет эту информацию. Кроме того, центр управления также сохраняет VTEP каждой сети VXLAN и эти адреса VETP. Используя эту информацию, VTEP напрямую запрашивает и добавляет заголовок при отправке сообщения, и нет необходимости в многоадресной рассылке по всей сети.
В распределенном центре управления при нормальных обстоятельствах эта архитектура запускает агент на каждом узле, где расположен VTEP. Он будет связываться с центром связи, чтобы получить информацию, необходимую для туннельной связи, и сообщить VTEP как-то.
(Если хотите, не забудьте поставить лайк и добавить в избранное!)