Способы настройки одноадресной передачи в VXLAN
В одной из предыдущих статей мы рассматривали особенности реализации многоадресной передачи в VXLAN (multicast). Однако на практике multicast доступен не всегда, да и управлять им при масштабировании бывает непросто. В таких случаях выручают расширения DOVE — они добавлены к реализации VXLAN в Linux 3.8 и избавляют системного архитектора от необходимости применения multicast.
Flooding — unicast-передача со статической лавинной рассылкой
При желании multicast можно заменить на реплицирование кадров BUM в статически сконфигурированный перечень удалённых VTEP:
VXLAN определяется без удалённой multicast-группы. Вместо этого, все существующие удалённые VTEP выполняют связь с нулевым адресом, то есть кадр BUM дублируется на все имеющиеся удалённые точки. При этом устройство VXLAN автоматически запоминает удалённые адреса, изучая адреса источников кадров.
По сути, перед нами довольно простое решение. Если добавить немного автоматизации, вы сможете без проблем поддерживать актуальность записей по дефолту в FDB. Но следует учесть, что хост должен будет дублировать каждый BUM-кадр (head-end replication) на все удалённые VTEP. Если их у вас с десяток, то никаких проблем. Но если тысячи, всё становится гораздо сложнее.
Пример использования этой стратегии (head-end replication) можно посмотреть здесь.
Unicast-передача со статическими записями L2
Если вы знаете связи MAC-адресов с VTEP, то сможете предконфигурировать FDB, а также отключить изучение адресов источников:
Используя флаг nolearning, вы отключите изучение адресов источников. А когда MAC отсутствует, то кадр всегда станет отправляться с применением нулевых записей. Такие записи нужны для широковещательного трафика и milticast-трафика (к примеру, для обнаружения соседей по ARP и IPv6). Данный вид настройки подойдёт для предоставления виртуальных сетей L2 виртуальным машинам (если информация L3 недоступна). Чтобы обновить записи FDB, потребуются какие-нибудь связанные записи.
Среди практических примеров этой стратегии — BGP EVPN и Cumulus Quagga.
Unicast-передача со статическими записями L3
В прошлом примере мы сохраняли все нулевые записи, что необходимо для корректного обнаружения соседей по ARP и IPv6. Но операционная система Linux способна ещё и отвечать на запросы соседей от имени удалённых узлов.
Если вы включите эту опцию, то записи по умолчанию станут не нужны (однако вы сможете их сохранять):
Эта настройка полностью исключит head-end replication. Но следует учесть, что не будут функционировать и протоколы, основанные на мультивещании. При наличии автоматизации данная настройка может хорошо работать с контейнерами: когда в реестре содержится перечень всех используемых IP- и MAC-адресов, программа сможет слушать его, настраивая FDB и соседние таблицы.
Пример — бэкенд VXLAN в Docker libnetwork. Правда, в нём ещё используется метод, о котором поговорим ниже.
Unicast-передача с динамическими записями L3
ОС Linux способна уведомлять программу, если отсутствуют записи (L2 либо L3). Программа обратится к центральному реестру и динамически добавит запрашиваемую запись. Но для L2-записей отправка уведомлений применяется лишь в некоторых случаях: • неизвестен MAC-адрес назначения, • в FDB отсутствует нулевая запись, • MAC-адрес назначения не является широковещательным и многоадресным.
Эти ограничения не позволят задействовать сценарий unicast-передачи с динамическими записями L2.
Итак, создадим устройство VXLAN с опциями 13miss и 12miss:
Уведомления отправляются программам, которые слушают сокет AF_NETLINK и используют протокол NETLINK_ROUTE. Данный сокет должен быть связан с группой RTNLGRP_NEIGH. Эта связь, как и декодирование полученных уведомлений, выполняется посредством:
Первое уведомление сообщит о том, что отсутствует запись соседа для запрошенного IP-адреса. Эту запись можно добавить так:
Но перед нами временная запись, а значит, по окончании срока действия удалять её не придётся. В случае устаревания записи поступит уведомление для обновления. В тот момент, когда хост получит ответ proxy на запрос на обнаружение соседей, он сможет отправить кадр с MAC-адресом, который мы указали в качестве адреса назначения. Второе уведомление относится к отсутствию FDB записи для данного MAC-адреса. Добавить соответствующую запись можно посредством другой команды:
Данная запись тоже временная — в обратном случае это могло бы помешать миграции MAC на локальный VTEP (дело в том, что динамическая запись не переопределяет постоянную запись).
Такая настройка хорошо работает с глобальным реестром и контейнерами. Но для первых подключений возможно запаздывание сигнала. Мало того, в транспортной сети мультивещание и широковещательная передача доступны не будут. Пример такой стратегии — бэкенд VXLAN в flannel (сетевая матрица для Kubernets).
По материалам статьи «VXLAN & Linux».
