В дата-центре сотня стоек, в каждой — свой коммутатор. Виртуальная машина живёт в стойке А, и её адрес — 192.168.100.11. Ночью гипервизор решает переселить её в стойку Б: там свободнее память.

Машина переезжает и должна остаться с тем же адресом. Не потому что так красивее, а потому что на этот адрес настроены балансировщик, правила фаервола, записи в конфигурации соседних сервисов. Смена адреса при каждом переезде превратила бы миграцию в проект на неделю.

Значит, подсеть 192.168.100.0/24 обязана существовать в обеих стойках одновременно. Причём машины в ней должны общаться напрямую, как в одном коммутаторе: увидеть друг друга по ARP, обменяться кадрами. А между стойками — маршрутизируемая сеть, которая про эту подсеть ничего не знает.

Первое, что приходит в голову — соединить все коммутаторы в один большой канальный сегмент и раздать VLAN по всем стойкам. Так и делали лет пятнадцать. Проблемы начинаются на масштабе.

Широковещание бьёт по всем. Один ARP-запрос от одной машины прилетает на каждый порт каждого коммутатора сегмента. Тысяча машин — и фоновый шум съедает заметную долю полосы, а всплеск (например, перезагрузка стойки) кладёт всё разом.

STP гасит половину линков. Чтобы не было петель, связующее дерево обязано заблокировать все избыточные пути. Вы купили восемь аплинков — работает один. Остальные семь ждут аварии.

Тегов всего 4094. Поле VLAN в заголовке — двенадцать бит. Для офиса это много, для облачного провайдера, где каждому клиенту нужен свой изолированный сегмент, это потолок, в который упираются быстро.

Домен отказа — весь дата-центр. Петля, сбойный порт, шторм — и лежит не одна стойка, а всё сразу. За такое увольняют.

Решение то же, что и в туннелях между площадками: если сеть посередине не умеет возить то, что нужно — спрячьте это внутрь того, что она возить умеет.

VXLAN берёт целый кадр Ethernet — с MAC-адресами, тегом, всем содержимым — и кладёт его внутрь обычного пакета UDP на порт 4789. Снаружи получается рядовой трафик между двумя адресами IP, который сеть между стойками маршрутизирует, ни о чём не догадываясь.

Между заголовком UDP и вложенным кадром лежат восемь байт самого VXLAN, и главное в них — VNI, номер сегмента. Он занимает двадцать четыре бита, то есть сегментов может быть около шестнадцати миллионов вместо четырёх тысяч. Для провайдера это разница между «места нет» и «места хватит всем».

Накладные расходы — 50 байт: новый IP, UDP и заголовок VXLAN. Запомните это число, к нему вернёмся.

Устройство, которое заворачивает кадр в пакет и разворачивает обратно, называется VTEP. Обычно это коммутатор стойки, иногда — сам гипервизор.

У VTEP есть адрес, и по нему его находят остальные. Адрес этот берут не с физического порта, а с loopback'а — виртуального интерфейса, который не привязан ни к какому кабелю. Причина простая: у коммутатора четыре аплинка, любой может отвалиться. Если бы туннель был привязан к порту, обрыв кабеля рвал бы все туннели разом. Loopback же не гаснет, пока жив сам коммутатор, а до него ведут все четыре пути — какой останется, по тому трафик и поедет.

Поэтому первое, что делают в такой сети, — добиваются, чтобы loopback'и всех коммутаторов видели друг друга. Без этого не поднимется ничего.

Кадр пришёл, его надо завернуть. Но в чей адрес? VTEP должен знать, за каким соседом стоит машина с нужным MAC-адресом.

Первый вариант — учиться на трафике, как обычный коммутатор. Неизвестный адрес? Разослать копию всем соседям сразу и посмотреть, кто ответит. Работает, но это ровно та проблема, от которой уходили: широковещание никуда не делось, просто теперь оно ещё и размножается на каждый туннель. На десятке стоек терпимо, на сотне — нет.

Второй вариант — рассказывать заранее. Пусть каждый коммутатор объявляет остальным: «вот эти MAC-адреса живут за мной». Тогда никакой рассылки вслепую: адрес известен ещё до того, как пришёл первый кадр. Нужен только протокол, по которому такие объявления передавать.

Протокол не стали изобретать заново. Взяли BGP — тот самый, что держит маршруты в интернете, — и научили его переносить сведения о канальном уровне. Это семейство называется l2vpn evpn, а вся конструкция — EVPN.

Выбор не случаен. BGP уже умеет всё, что здесь нужно: работать на тысячах устройств, фильтровать объявления политиками, собирать сессии через отражатели маршрутов вместо связи каждого с каждым. Инженеры его знают, инструменты для него есть.

По EVPN коммутаторы рассылают друг другу несколько видов объявлений. Два главных:
— «за мной такой-то MAC» — адрес машины плюс номер сегмента, в котором она живёт. Часто вместе с её IP, и тогда сосед может отвечать на ARP локально, вообще не пуская запрос по сети.
— «я обслуживаю такой-то сегмент» — по этим объявлениям коммутаторы узнают, кому вообще имеет смысл слать широковещание в этом VNI. Не всем подряд, а только тем, у кого этот сегмент есть.

Отсюда и деление ролей, которое стоит держать в голове: VXLAN — как везём, EVPN — откуда знаем, кому везти. Одно без другого работает плохо: VXLAN без EVPN скатывается в рассылку вслепую, а EVPN без VXLAN просто нечем возить.

Такая сеть распадается на два слоя, и путать их — верный способ потерять вечер.

Подложка — обычная маршрутизируемая сеть между коммутаторами. Адреса линков, loopback'и, протокол маршрутизации. Её задача одна: чтобы любой loopback дошёл до любого. Никаких VLAN, никакого STP, все линки в работе.

Наложение — туннели и сегменты арендаторов, которые живут поверх. Подложка про них не знает и знать не должна: для неё это просто трафик UDP между своими же адресами.

Физически всё это обычно собирают спайнами и листьями: коммутаторы стоек (листья) втыкаются в коммутаторы ядра (спайны), листья между собой не соединяются. Путь от любой стойки до любой — ровно два перехода, и путей столько, сколько спайнов. Трафик размазывается по ним всем, а не жмётся в один незаблокированный линк, как это было бы с деревом.

Практический вывод: когда что-то не работает, сначала выясните, какой слой сломан. Не видят друг друга loopback'и — чините подложку, EVPN здесь ни при чём. Loopback'и пингуются, а сегмент разорван — тогда уже наложение.

Вернёмся к накладным расходам. Машина отправляет кадр с полутора тысячами байт данных — стандартный размер, никто его не менял. Коммутатор добавляет пятьдесят байт заголовков, и в подложку уезжает пакет размером больше полутора тысяч.

Если подложка настроена на обычные 1500, такой пакет не пролезет. Причём сломается это подло: маленькие пакеты ходят, ping отвечает, ARP работает — а копирование файла виснет намертво, и веб-страницы открываются наполовину.

Поэтому в подложке всегда поднимают MTU с запасом — обычно до 9000. Проверять это надо не пингом по умолчанию, а полноразмерным пакетом с запретом фрагментации: ping -M do -s 1472. Прошёл — сеть готова; молчит — разбирайтесь с MTU, а не с EVPN.

Порядок такой же, как и слои — снизу вверх.

Подложка. Видят ли loopback'и друг друга: ping с одного на другой, именно с loopback-адреса как источника. Знает ли промежуточный коммутатор оба адреса: show ip route.

Сессия. show bgp l2vpn evpn summary — и обратите внимание на команду. Обычный show bgp summary покажет сессию в семействе адресов IPv4, и она может быть прекрасно поднята, пока EVPN не работает вовсе. Спрашивать надо про то семейство, которое нужно.

Объявления. В той же сводке есть счётчик принятых префиксов. Ноль при поднятой сессии означает, что сосед молчит: скорее всего, ему не сказали объявлять свои сегменты.

Сегмент. show evpn vni — есть ли нужный VNI и сколько у него удалённых VTEP. Ноль удалённых означает, что вторая сторона про себя не рассказала.

Адреса. show evpn mac vni 100 — чужие MAC-адреса должны быть помечены как удалённые. Если их там нет, а связи нет тем более, — вы нашли, где обрыв.