Vxlan что это такое
Настройка VXLAN
Параметры загрузки
Об этом переводе
Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
Содержание
Введение
В этом документе представлен общий обзор виртуальной расширяемой локальной сети (VXLAN), а также приведено нескольких примеров конфигурации, команд проверки и выходных данных.
Предварительные условия
Требования
Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:
В этом документе предполагается, что перед настройкой VXLAN уже настроены IP-маршрутизация и многоадресная маршрутизация.
Используемые компоненты
Сведения, содержащиеся в данном документе, касаются следующих версий программного обеспечения и оборудования:
Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.
Общие сведения
Терминология
VXLAN (виртуальная расширяемая локальная сеть) —- технология, которая предоставляет те же сетевые сервисы Ethernet уровня 2, что и современная сеть VLAN, но с большей степенью расширяемости и адаптивности.
VNID (идентификатор сети Vxlan) — 24-разрядный идентификатор сегмента, который определяет домен широковещательной рассылки. То же, что и идентификатор сегмента VXLAN.
VTEP (виртуальное оконечное устройство туннеля) — устройство, которое выполняет инкапсуляцию и декапсуляцию.
NVE (виртуальный сетевой интерфейс) — логический интерфейс, где происходит инкапсуляция и декапсуляция.
Что такое VXLAN?
VXLAN решает три следующие главные проблемы:
Преимущества использования VXLAN?
Настройка
Схема сети
Конфигурации
Эти конфигурации относятся к части VXLAN в конфигурации. Обратите внимание, что 9396-A и 9396-B находятся в домене vPC, а 3172-A — нет. Эти конфигурации предполагают полную достижимость всех интерфейсов L3 в топологии с протоколом маршрутизации по вашему выбору. В данном примере использовался протокол OSPF. Кроме того, предполагается, что многоадресная маршрутизация установлена по этим же интерфейсам L3.
3172-A
9396-A
Примечание. Когда vPC используются в качестве VTEP, вторичный IP-адрес интерфейса обратной петли совместно используется двумя одноранговыми узлами. Таким образом, оба одноранговых узла представляют себя удаленным узлам NVE как одиночные VTEP.
9396-B
Примечание. Когда vPC используются в качестве VTEP, вторичный IP-адрес интерфейса обратной петли совместно используется двумя одноранговыми узлами. Таким образом, оба одноранговых узла представляют себя удаленным узлам NVE как одиночные VTEP.
Проверка
Этот раздел позволяет убедиться, что конфигурация работает правильно.
Устранение неполадок
Для этой конфигурации в настоящее время нет сведений об устранении проблем.
VxLAN фабрика. Часть 1
Привет, хабр. В настоящее время я являюсь руководителем курса «Сетевой инженер» в OTUS.
В преддверии старта нового набора на курс «Сетевой инженер», я подготовил цикл статей по технологии VxLAN EVPN.
Существует огромное множество материалов по работе VxLAN EVPN, поэтому я хочу собрать различные задачи и практики решения задач в современном ЦОД.
В первой части цикла по технологии VxLAN EVPN хочу рассмотреть способ организации L2 cвязанности между хостами поверх сетевой фабрики.
Все примеры будем выполнять на Cisco Nexus 9000v, собранных в топологию Spine-Leaf. Останавливаться на настройке Underlay сети в рамках этой статьи мы не будем.
Underlay сеть
Используемая топология выглядит следующим образом:
Зададим адресацию на всех устройствах:
Проверим что есть IP связанность между всеми устройствами:
Проверим, что VPC домен создан и оба коммутатора прошли проверку консистенции и настройки на обеих нодах идентичны:
BGP пиринг
Наконец можно перейти к настройке Overlay сети.
В рамках статьи необходимо организовать сеть между хостами, как показано на схеме ниже:
Для настройки Overlay сети необходимо на Spine и Leaf коммутаторах включить BGP с поддержкой семейства l2vpn evpn:
Далее необходимо настроить BGP пиринг между Leaf и Spine. Для упрощения настройки и оптимизации распространения маршрутной информации Spine настраиваем в качестве Route-Reflector server. Все Leaf пропишим в конфиге через шаблоны, чтобы оптимизировать настройку.
Таким образом настройки на Spine выглядит так:
Настройка на Leaf коммутаторе выглядит аналогичным образом:
На Spine проверим пиринг со всеми Leaf коммутаторами:
Как видим, с BGP никаких проблем не возникло. Перейдем к настройке VxLAN. Дальнейшая настройка будет производиться только на стороне Leaf коммутаторов. Spine выступает только в качестве ядра сети и занимаются только передачей трафика. Вся работа по инкапсуляции и определении пути происходит только на Leaf коммутаторах.
Настройка NVE
NVE — network virtual interface
Перед началом настройки введем немного терминологии:
VTEP — Vitual Tunnel End Point, устройство на котором начинается или заканчивается VxLAN тоннель. VTEP это не обязательно какое-либо сетевое устройство. Так же может выступать и сервер с поддержкой технологии VxLAN. В нашей топологии все Leaf коммутаторы являются VTEP.
VNI — Virtual Network Index — идентификатор сети в рамках VxLAN. Можно провести аналогию с VLAN. Однако есть некоторые отличия. При использовании фабрики, VLAN становятся уникальными только в рамках одного Leaf коммутатора и не передаются по сети. Но с каждым VLAN может быть проассоциирован номер VNI, который уже передается по сети. Как это выглядит и как это можно использовать будет рассмотрено далее.
Включим feature для работы технологии VxLAN и возможность ассоциировать номера VLAN с номером VNI:
Настроим интерфейс NVE, который отвечает за работу VxLAN. Данный интерфейс как раз и отвечает за инкапсуляцию кадров в VxLAN заголовки. Можно провести аналогию с Tunnel интерфейсом для работы GRE:
Host-2 отправляет один кадр в сторону Leaf-21, чтобы тот передал его по сети в сторону Host-1. Однако Leaf-21 видит что MAC адрес Host-1 доступен сразу через два VTEP. Как в этом случае поступить Leaf-21? Ведь это значит что в сети могла появиться петля.
Для решения этой ситуации нам необходимо чтобы Leaf-11 и Leaf-12 в рамках фабрики так же выступали одним устройством. Решается это довольно просто. На интерфейсе Loopback с которого строим тоннель, добавляем secondary адрес. Secondary адрес должен быть одинаковым на обоих VTEP.
Таким образом с точки зрения других VTEP мы получаем следующую топологию:
То есть теперь тоннель будет строиться между IP адресом Leaf-21 и виртуальным IP между двумя Leaf-11 и Leaf-12. Теперь проблем с изучением MAC адреса от двух устройств возникать не будет и трафик может переходить от одного VTEP на другой. Кто именно из двух VTEP обработает трафик решается с помощью таблицы маршрутизации на Spine:
Как видно выше адрес 10.255.1.10 доступен сразу через два Next-hop.
На данной этапе разобрались с базовой связанностью. Перейдем к настройке интерфейса NVE:
Сразу включим Vlan 10 и проассоциируем его с VNI 10000 на каждом Leaf для хостов. Настроим L2 тоннель между хостами
Теперь проверим nve peers и таблицу для BGP EVPN:
Выше видим маршруты только EVPN route-type 3. Данный тип маршрутов рассказывает о peer(Leaf), однако где же наши хосты?
А дело все в том, что информация о MAC хостов передается через EVPN route-type 2
Для того чтобы увидеть наши хосты необходимо настроить EVPN route-type 2:
Сделаем ping с Host-2 на Host-1:
И ниже мы можем видеть, что в таблице BGP появились route-type 2 c MAC адресом хостов — 5001.0007.0007 и 5001.0008.0007
Далее можно посмотреть подробную информацию по Update, в котором получили информацию о MAC Host. Ниже представлен не весь вывод команды
Давайте посмотрим как выглядят кадры, когда они передаются через фабрику:
Suppress-ARP
Отлично, L2 связь между хостами у нас появилась и на этом можно было бы закончить. Однако не все так просто. Пока у нас мало хостов проблем не возникнет. Но давайте представим ситуации, что хостов у нас сотни и тысячи. С какой проблемой мы можем столкнуться?
Эта проблема — BUM(Broadcast, Unknown Unicast, Multicast) трафик. В рамках этой статьи рассмотрим вариант борьбы с broadcast трафиком.
Основной генератор Broadcast в Ethernet сетях сами хосты через протокол ARP.
На nexus реализован следующий механизм для борьбы с ARP запросами — suppress-arp.
Работа данной фичи выглядит следующим образом:
Таким образом Broadcast запрос не ушел в фабрику. Но как это может работать, если Leaf знает только MAC адрес?
Все довольно просто, EVPN route-type 2 помимо MAC адреса может передавать связку MAC/IP. Для этого на Leaf необходимо настроить IP адрес в VLAN. Появляется вопрос, какой IP задать? На nexus есть возможность создать распределенный (одинаковый) адрес на всех коммутаторах:
Таким образом с точки зрения хостов сеть будет выглядеть следующим образом:
Проверим BGP l2route evpn
Из вывода команды видно, что в EVPN route-type 2 помимо MAC теперь видим еще и IP адрес хоста.
Возвращаемся к настройке suppress-arp. Включается эта настройка для каждого VNI отдельно:
Дальше возникает некоторая сложность:
Для данной настройки потребуется double-wide. То есть если задаете 256, то в TCAM необходимо освободить 512. Настройка TCAM выходит за пределы данной статьи, так как настройка TCAM зависит только от задачи поставленной перед Вами и может отличаться от одной сети к другой.
В результате надо как следует подумать, стоит ли в вашей ситуации внедрить данную настройку на работающую фабрику.
На этом закончим первую часть цикла. В следующей части рассмотрим маршрутизацию через VxLAN фабрику с разделением сетей по различным VRF.
А сейчас приглашаю всех на бесплатный вебинар, в рамках которого я подробно расскажу про курс. Первые 20 участников, зарегистрировавшихся на этот вебинар, получат Сертификат на скидку на электронную почту в течение 1-2 дней после трансляции.
Русские Блоги
Подробное объяснение и практика 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 как-то.
(Если хотите, не забудьте поставить лайк и добавить в избранное!)
Опыт реализации сетевых фабрик на базе EVPN VXLAN и Cisco ACI и небольшое сравнение
Оцените связки в средней части схемы. Ниже к ним вернёмся
В какой-то момент вы можете столкнуться с тем, что большие сложные сети на базе L2 неизлечимо больны. В первую очередь проблемами, связанными с обработкой BUM трафика и с работой протокола STP. Во вторую — в целом морально устаревшей архитектурой. Это вызывает неприятные проблемы в виде даунтаймов и неудобства управляемости.
У нас было два параллельных проекта, где заказчики трезво оценили все плюсы и минусы вариантов и выбрали два разных оверлейных решения, а мы их внедрили.
Была возможность сравнить именно реализацию. Не эксплуатацию, про неё стоит говорить года через два-три.
Итак, что такое сетевая фабрика с наложенными сетями и SDN?
Что делать с наболевшими проблемами классической архитектуры сети?
Каждый год появляются новые технологии и идеи. На практике горячая необходимость перестраивать сети не возникала довольно долго, потому что делать всё руками по старым добрым дедовским методам тоже можно. Ну и что, что на дворе двадцать первый век? В конце концов, админ же должен работать, а не сидеть у себя в кабинете.
Потом начался бум строительства масштабных дата-центров. Тогда стало понятно, что достигнут лимит развития классической архитектуры не только в плане работоспособности, отказоустойчивости, масштабируемости. И одним из вариантов решения этих задач стала идея построения наложенных сетей поверх маршрутизируемого бэкбона.
Помимо этого, с увеличением масштабов сетей остро встала проблема управления такими фабриками, в результате чего стали появляться решения программно-определяемых сетей с возможностью управлять всей сетевой инфраструктурой как единым целым. А когда сеть управляется из единой точки, то другим компонентам ИТ-инфраструктуры проще с ней взаимодействовать, и такие процессы взаимодействия проще автоматизировать.
Практически каждый крупный производитель не только сетевого оборудования, но и виртуализации, имеет в своём портфолио варианты таких решений.
Остаётся только разобраться, что подойдёт для каких потребностей. Например, для особо крупных компаний обладающих хорошей командой разработчиков и эксплуатации, не всегда коробочные решения от вендоров удовлетворяют всем потребностям, и они прибегают к разработке собственных SD (software defined) решений. Например, это облачные провайдеры, которые постоянно расширяют ассортимент сервисов предоставляемых своим клиентам, и коробочные решения просто не в состоянии успеть за их потребностями.
Для средних компаний, функционала, предлагаемого вендором в виде коробочного решения, хватает в 99 процентов случаев.
Что это такое оверлейные сети
В чём заключается идея оверлейных сетей. По сути, вы берёте классическую маршрутизируемую сеть и строите поверх неё ещё одну сеть, чтобы получить больше фич. Чаще всего речь об эффективном распределении нагрузки на оборудование и линии связи, значительном увеличении лимита по масштабируемости, повышении надёжности и куче плюшек в безопасности (за счёт сегментации). А SDN решения в дополнении к этому дают возможность очень, очень, очень удобного гибкого администрирования и делают сеть более прозрачной для её потребителей.
В общем, если бы локальные сети изобретали в годах этак 2010-х, то они бы выглядели далеко не так, как то, что досталось нам по наследству от военных из 1970-х.
С точки зрения технологий построения фабрик с использованием наложенных сетей, в настоящее время существует множество реализаций производителей и интернет-проектов RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve и другие). Да есть стандарты, но реализация этих стандартов различными производителями может отличаться, поэтому при создании таких фабрик полностью отказаться от вендор-лока пока можно лишь в теории на бумаге.
С SD решением дела обстоят ещё запутаннее, каждый вендор имеет своё видение. Есть полностью открытые решения, которые в теории можно допиливать самому, есть полностью закрытые.
Cisco предлагает свой вариант SDN для ЦОД — ACI. Естественно это 100 % вендор-лок решение с точки зрения выбора сетевого оборудования, но при этом оно полностью интегрируется с системами виртуализации, контейнеризации, безопасности, оркестрации, балансировщиками нагрузки и др. Но по сути это всё равно некий блэк бокс, без возможности полного доступа ко всем внутренним процессам. Не все заказчики соглашаются на такой вариант, так как ты полностью зависишь от качества написанного кода решения и его реализации, но с другой стороны производитель обладает одной из лучших в мире технических поддержек и имеет выделенную команду, занимающуюся только данным решением. В качестве решения для первого проекта был выбран именно Cisco ACI.
Для второго проекта было выбрано решение на Juniper. У производителя также есть свой SDN для ЦОД, но заказчиком было принято решение отказаться от внедрения SDN. В качестве технологии построения сети была выбрана EVPN VXLAN фабрика без использования централизованных контроллеров.
Для чего нужно
Создание фабрики позволяет построить легко масштабируемую, отказоустойчивую, надёжную сеть. Архитектура (leaf-spine) учитывает особенности центров обработки данных (пути прохождения трафика, минимизация задержек и узких мест в сети). SD решения же в ЦОДах позволяют очень удобно, быстро, гибко управлять такой фабрикой, интегрировать её в экосистему ЦОД.
Обоим заказчикам был необходимо построить резервные ЦОДы для обеспечения отказоустойчивости, помимо этого трафик между ЦОДами должен был шифроваться.
Первый заказчик уже рассматривал решения без фабрики как возможный стандарт своих сетей, но на тестах у них были проблемы с совместимостью STP между несколькими вендорами железа. Возникали даунтаймы, которые вызывали падения сервисов. А для заказчика это было критично.
Cisco уже была корпоративным стандартом заказчика, они присмотрелись к ACI и другим вариантам и решили, что стоит взять именно это решение. Понравилась автоматизация управления с одной кнопки через единый контроллер. Быстрее настраиваются сервисы, быстрее управляются. Шифрование трафика решили обеспечить запустив MACSec между коммутаторами IPN и SPINE. Таким образом удалось избежать узкого места в виде криптошлюза, сэкономить на них и использовать по максимуму полосу пропускания.
Второй заказчик выбрал решение без контроллера от Juniper, поскольку в их существующем ЦОД уже была небольшая инсталляция с реализацией фабрики EVPN VXLAN. Но там она не была отказоустойчивой (использовался один коммутатор). Приняли решение расширить инфраструктуру основного ЦОД и построить фабрику в резервном ЦОД. Имеющийся EVPN не использовался в полной мере: инкапсуляция VXLAN фактически не применялась, так как все хосты были подключены к одному коммутатору, и все MAC-адреса и /32 адреса хостов были локальными, шлюзом для них являлся этот же коммутатор, не было других устройств, куда необходимо было строить VXLAN тоннели. Шифрование трафика решили обеспечить с использованием технологии IPSEC между файрволами (производительности МСЭ было достаточно).
Тоже пощупали ACI, но решили, что из-за вендор-лока придётся покупать слишком много железа, в том числе заменять недавно купленное новое оборудование, и это просто не имеет экономического смысла. Да, фабрика Cisco интегрируется со всем, но внутри самой фабрики возможны только её устройства.
С другой стороны, как говорили ранее, EVPN VXLAN фабрику с любым соседним вендором просто так не смешаешь, потому что реализации протокола отличаются. Это как скрещивать Cisco и Хуавей в одной сети — вроде бы, стандарты общие, только с бубном поплясать придётся. Поскольку это банк, и тесты на совместимость были бы очень долгими, решили, что лучше закупиться тем же вендором сейчас, и не особо увлекаться функционалом за пределами базового.
План миграции
Два ЦОДа на базе ACI:
Организация взаимодействия между ЦОДами. Выбрано Multi-Pod решение — каждый ЦОД является подом. Учтены требования к масштабированию по количеству коммутаторов и к задержкам между подами (RTT менее 50 мс). Было принято решение не строить Multi-Site решение для удобства управления (для Multi-Pod решения используется единый интерфейс управления, для Multi-Site было бы два интерфейса, либо потребовался бы Multi-Site Orchestrator), и так как не требовалось географического резервирования площадок.
С точки зрения миграции сервисов из Legacy сети, был выбран наиболее прозрачный вариант, переносить постепенно VLAN соответствующие определённым сервисам.
Для миграции каждому VLAN создавался соответствующий EPG (End-point-group) на фабрике. Сначала сеть растягивалась между старой сетью и фабрикой по L2, затем после миграции всех хостов, шлюз переносился на фабрику, и взаимодействие EPG с существующей сетью производилось через L3OUT, при этом взаимодействие между L3OUT и EPG описывалось с использованием контрактов. Примерная схема:
Примерная структура большинства политик фабрики ACI на рисунке ниже. Вся настройка строится на политиках, вложенных в другие политики и так далее. Поначалу очень непросто разобраться, но постепенно, как показывает практика, администраторы сети привыкают к такой структуре примерно за месяц, и потом только приходит понимание насколько она удобна.
Сравнение
В решении Cisco ACI нужно покупать больше оборудования (отдельные коммутаторы для Inter-Pod взаимодействия и APIC контроллеры), за счёт чего оно получилось дороже. Решение Juniper не потребовало покупку контроллеров и вспомогательного оборудования; получилось частично использовать уже существующее оборудование заказчика.
Вот архитектура EVPN VXLAN фабрики для двух ЦОДов второго проекта:
В ACI ты получаешь готовое решение — не надо ковырять, не надо оптимизировать. При первоначальном знакомстве заказчика с фабрикой не нужны разработчики, не нужны поддерживающие люди для кода и автоматизации. Достаточно просто эксплуатации, многие настройки можно делать вообще через визард, что не всегда плюс, особенно для людей, привыкших к командной строке. В любом случае нужно время для того, чтобы перестроить мозг на новые рельсы, на особенность настроек через политики и оперированием множества вложенных друг в друга политик. Очень желательно, помимо этого, ещё иметь чёткую структуру наименования политик и объектов. При возникновении какой-либо проблемы в логике работы контроллера, её решить можно только через техподдержку.
В EVPN — консоль. Страдай или радуйся. Привычный интерфейс для старой гвардии. Да, есть типовая конфигурация и гайды. Придётся курить маны. Разные конструкции, всё понятно и детально.
Естественно, в обоих случаях лучше при миграции сначала мигрировать не самые критичные сервисы, например, тестовые среды, и только потом после поимки всех багов приступать к проду. И не настраивать в пятницу вечером. Не стоить верить вендору, что все будет ок, всегда лучше подстраховаться.
На ACI платишь больше, хотя в настоящее время Cisco активно продвигает это решение и зачастую даёт хорошие скидки на него, но экономишь на обслуживании —сопровождении. Управление и какая-либо автоматизация EVPN фабрики без контроллера требует вложений и регулярных затрат — мониторинг, автоматизация, внедрение новых сервисов. При этом первичный запуск у ACI делается дольше на 30–40 процентов. Это происходит потому, что дольше создаётся весь набор необходимых профилей и политик, которые затем будут использоваться. Но по мере роста сети количество нужных конфигураций уменьшается. Используешь уже заранее созданные политики, профили, объекты. Можешь гибко настраивать сегментацию и безопасность, централизованно управлять контрактами, которые отвечают за разрешение тех или иных взаимодействий между EPG, — объём работы резко падает.
В EVPN надо конфигурировать каждое устройство в фабрике, вероятность ошибки больше.
Если ACI медленнее внедряется, то EVPN почти вдвое дольше отлаживался. Если в случае с Cisco всегда можно позвать инженера поддержки и спросить про сеть в целом (потому что покрывается как решение), то у Juniper Networks вы покупаете только железо, и покрывается именно оно. Пакеты с устройства ушли? Ну ок, дальше ваши проблемы. Но можно открыть вопрос по выбору решения или дизайну сети — и тогда посоветуют приобрести профешнл сервис, за дополнительную плату.
ACI поддержка очень крутая, потому что отдельная: отдельная команда сидит только для этого. Есть, в том числе и русскоязычные спецы. Гайд подробный, решения предопределены. Смотрят и советуют. Быстро валидируют дизайн, что часто важно. Juniper Networks делают то же самое, но в разы медленнее (у нас было так, сейчас должно быть лучше по слухам), что заставляет тебя самостоятельно делать всё там, где мог бы посоветовать солюшн-инженер.
Cisco ACI поддерживает интеграцию с системами виртуализации и контейнеризации (VMware, Kubernetes, Hyper-V) и централизованное управление. Есть с сетевыми сервисами и сервисами безопасности — балансировка, межсетевые экраны, WAF, IPS и прочее… Хорошая микросегментация из коробки. Во втором решении интеграция с сетевыми сервисами проходится с бубном, и лучше заранее курить форумы с теми, кто так делал.
Для каждого конкретного случая необходимо подбирать решение, не только исходя из стоимости оборудовании, но и необходимо учитывать также дальнейшие расходы на эксплуатацию и основные проблемы, с которыми сталкивается заказчик сейчас, и какие есть планы по развитию ИТ-инфраструктуры.
ACI за счёт дополнительного оборудования вышел дороже, но решение готовое без необходимости допиливания, второе решение более сложно и затратно с точки зрения эксплуатации, но дешевле.
Если хотите обсудить, сколько может стоить внедрение сетевой фабрики на разных вендорах, и какая нужна архитектура, — можно встретиться и пообщаться. До чернового наброска архитектуры (с которым можно считать бюджеты) подскажем бесплатно, детальная проработка, естественно, уже платная.
Владимир Клепче, корпоративные сети.