Способы настройки одноадресной передачи в VXLAN | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Python Developer. Professional
-3%
Разработчик на Spring Framework
-5%
iOS Developer. Professional
-8%
Golang Developer. Professional
-6%
Базы данных
-12%
Agile Project Manager
-5%
Android Developer. Professional
-11%
Microservice Architecture
-5%
C++ Developer. Professional
-5%
Highload Architect
-6%
JavaScript Developer. Basic
-8%
Backend-разработчик на PHP
-9%
Архитектура и шаблоны проектирования C# Developer. Professional
-9%
Team Lead
-6%
Kotlin Backend Developer
-9%
Разработчик программных роботов (RPA) на базе UiPath и PIX Unity Game Developer. Basic Разработчик голосовых ассистентов и чат-ботов Node.js Developer Интенсив «Оптимизация в Java» Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes iOS Developer. Basic Супер-интенсив «СУБД в высоконагруженных системах» Супер-интенсив "Tarantool"
Инфраструктура
DevOps практики и инструменты
-12%
Базы данных
-12%
Network engineer. Basic
-10%
Network engineer
-4%
Инфраструктурная платформа на основе Kubernetes
-6%
Экспресс-курс по управлению миграциями (DBVC)
-10%
Мониторинг и логирование: Zabbix, Prometheus, ELK
-10%
Administrator Linux. Professional
-6%
Разработчик IoT
-13%
Основы Windows Server Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов VOIP инженер Супер-практикум по работе с протоколом BGP NoSQL Супер-практикум по использованию и настройке GIT Супер-интенсив «СУБД в высоконагруженных системах» Экспресс-курс «IaC Ansible»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Способы настройки одноадресной передачи в VXLAN

В одной из предыдущих статей мы рассматривали особенности реализации многоадресной передачи в VXLAN (multicast). Однако на практике multicast доступен не всегда, да и управлять им при масштабировании бывает непросто. В таких случаях выручают расширения DOVE — они добавлены к реализации VXLAN в Linux 3.8 и избавляют системного архитектора от необходимости применения multicast.

Flooding — unicast-передача со статической лавинной рассылкой

При желании multicast можно заменить на реплицирование кадров BUM в статически сконфигурированный перечень удалённых VTEP:

Screenshot_1-1801-3c1ac2.png

VXLAN определяется без удалённой multicast-группы. Вместо этого, все существующие удалённые VTEP выполняют связь с нулевым адресом, то есть кадр BUM дублируется на все имеющиеся удалённые точки. При этом устройство VXLAN автоматически запоминает удалённые адреса, изучая адреса источников кадров.

По сути, перед нами довольно простое решение. Если добавить немного автоматизации, вы сможете без проблем поддерживать актуальность записей по дефолту в FDB. Но следует учесть, что хост должен будет дублировать каждый BUM-кадр (head-end replication) на все удалённые VTEP. Если их у вас с десяток, то никаких проблем. Но если тысячи, всё становится гораздо сложнее.

Пример использования этой стратегии (head-end replication) можно посмотреть здесь.

Unicast-передача со статическими записями L2

Если вы знаете связи MAC-адресов с VTEP, то сможете предконфигурировать FDB, а также отключить изучение адресов источников:

Screenshot_2-1801-a83ef1.png

Используя флаг nolearning, вы отключите изучение адресов источников. А когда MAC отсутствует, то кадр всегда станет отправляться с применением нулевых записей. Такие записи нужны для широковещательного трафика и milticast-трафика (к примеру, для обнаружения соседей по ARP и IPv6). Данный вид настройки подойдёт для предоставления виртуальных сетей L2 виртуальным машинам (если информация L3 недоступна). Чтобы обновить записи FDB, потребуются какие-нибудь связанные записи.

Среди практических примеров этой стратегии — BGP EVPN и Cumulus Quagga.

Unicast-передача со статическими записями L3

В прошлом примере мы сохраняли все нулевые записи, что необходимо для корректного обнаружения соседей по ARP и IPv6. Но операционная система Linux способна ещё и отвечать на запросы соседей от имени удалённых узлов.

Если вы включите эту опцию, то записи по умолчанию станут не нужны (однако вы сможете их сохранять):

Screenshot_3-1801-348991.png

Эта настройка полностью исключит head-end replication. Но следует учесть, что не будут функционировать и протоколы, основанные на мультивещании. При наличии автоматизации данная настройка может хорошо работать с контейнерами: когда в реестре содержится перечень всех используемых IP- и MAC-адресов, программа сможет слушать его, настраивая FDB и соседние таблицы.

Пример — бэкенд VXLAN в Docker libnetwork. Правда, в нём ещё используется метод, о котором поговорим ниже.

Unicast-передача с динамическими записями L3

ОС Linux способна уведомлять программу, если отсутствуют записи (L2 либо L3). Программа обратится к центральному реестру и динамически добавит запрашиваемую запись. Но для L2-записей отправка уведомлений применяется лишь в некоторых случаях: • неизвестен MAC-адрес назначения, • в FDB отсутствует нулевая запись, • MAC-адрес назначения не является широковещательным и многоадресным.

Эти ограничения не позволят задействовать сценарий unicast-передачи с динамическими записями L2.

Итак, создадим устройство VXLAN с опциями 13miss и 12miss:

Screenshot_4-1801-93ad04.png

Уведомления отправляются программам, которые слушают сокет AF_NETLINK и используют протокол NETLINK_ROUTE. Данный сокет должен быть связан с группой RTNLGRP_NEIGH. Эта связь, как и декодирование полученных уведомлений, выполняется посредством:

Screenshot_5-1801-653172.png

Первое уведомление сообщит о том, что отсутствует запись соседа для запрошенного IP-адреса. Эту запись можно добавить так:

Screenshot_6-1801-06d910.png

Но перед нами временная запись, а значит, по окончании срока действия удалять её не придётся. В случае устаревания записи поступит уведомление для обновления. В тот момент, когда хост получит ответ proxy на запрос на обнаружение соседей, он сможет отправить кадр с MAC-адресом, который мы указали в качестве адреса назначения. Второе уведомление относится к отсутствию FDB записи для данного MAC-адреса. Добавить соответствующую запись можно посредством другой команды:

Screenshot_7-1801-a9211e.png

Данная запись тоже временная — в обратном случае это могло бы помешать миграции MAC на локальный VTEP (дело в том, что динамическая запись не переопределяет постоянную запись).

Такая настройка хорошо работает с глобальным реестром и контейнерами. Но для первых подключений возможно запаздывание сигнала. Мало того, в транспортной сети мультивещание и широковещательная передача доступны не будут. Пример такой стратегии — бэкенд VXLAN в flannel (сетевая матрица для Kubernets).

По материалам статьи «VXLAN & Linux».

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться