Способы настройки одноадресной передачи в VXLAN | OTUS
🔥 BLACK FRIDAY!
Максимальная скидка -25% на всё. Успейте начать обучение по самой выгодной цене.
Выбрать курс

Курсы

Программирование
iOS Developer. Basic
-25%
Python Developer. Professional
-25%
Разработчик на Spring Framework
-25%
Golang Developer. Professional
-25%
Python Developer. Basic
-25%
iOS Developer. Professional
-25%
Highload Architect
-25%
JavaScript Developer. Basic
-25%
Kotlin Backend Developer
-25%
JavaScript Developer. Professional
-25%
Android Developer. Basic
-25%
Unity Game Developer. Basic
-25%
Разработчик C#
-25%
Программист С Web-разработчик на Python Алгоритмы и структуры данных Framework Laravel PostgreSQL Reverse-Engineering. Professional CI/CD Vue.js разработчик VOIP инженер Программист 1С Flutter Mobile Developer Супер - интенсив по Kubernetes Symfony Framework Advanced Fullstack JavaScript developer Супер-интенсив "Azure для разработчиков"
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK
-25%
DevOps практики и инструменты
-25%
Архитектор сетей
-25%
Инфраструктурная платформа на основе Kubernetes
-25%
Супер-интенсив «IaC Ansible»
-16%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-25%
Супер-интенсив "SQL для анализа данных"
-16%
Базы данных Сетевой инженер AWS для разработчиков Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT IoT-разработчик Супер-интенсив «ELK»
Специализации Курсы в разработке Подготовительные курсы
+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 комментариев
Для комментирования необходимо авторизоваться
🎁 Максимальная скидка!
Черная пятница уже в OTUS! Скидка -25% на всё!