Привет, это Данил Киселев, сетевой инженер в Yandex Infrastructure. Представьте себе, что у вас не просто офис, а очень большой офис с тысячами пользователей, которые ходят с созвона на созвон, перемещаясь между переговорками. Разумеется, им хочется оставаться на связи в процессе и не думать о ближайших точках доступа к Wi‑Fi. Для сетевого инженера это не выглядит проблемой на небольших масштабах. Но что если скоро ваш офис вырастет и таких точек доступа в сетевой фабрике может стать уже 20 000 и больше?

В статье расскажу про опыт использования технологии VxLAN в корпоративных сетях Яндекса. В частности речь пойдёт про построение Wi‑Fi поверх VxLAN‑туннелей, которые таким образом смогли помочь нам с большим доменом и заодно избежать широковещательного шторма.

Что такое опорная сеть и зачем она нужна  

На конференции nexthop в 2024 году мои коллеги Дима Литовченко @ttl256 и Паша Семенищев @htechno уже рассказывали про офисную магистраль, внешнюю связанность и про Wi‑Fi в Яндексе. В этом посте остановимся на достаточно важной части сети, которая находится между офисной магистралью и конечной Wi‑Fi‑точкой доступа. Мы называем такую сеть опорной сетью для Wi‑Fi. 

Для себя мы сформировали несколько критериев хорошей опорной сети для Wi‑Fi:

  1. Она должна быть универсальной. Мы хотим поддерживать один дизайн, который хорошо работает как в небольших локациях, так и в очень больших.

  2. Выбор дизайна для Wi‑Fi не должен зависеть от опорной сети. Надо учитывать, что технология Wi‑Fi постоянно развивается: появляются новые протоколы, стандарты, архитектуры.

  3. Мы не хотим замыкаться на одного производителя. Стоит использовать только те технологии и стандарты, которые поддерживаются большинством, для того чтобы в любой момент можно было сменить вендора. 

  4. Хорошая опорная сеть для Wi‑Fi умеет масштабироваться. 

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

  5. Изоляция пользовательского трафика друг от друга, но на опорной сети. Это можно сделать с помощью Wi‑Fi‑точек доступа. Но не на всех точках доступа поддерживается эта функциональность, и не всегда это возможно реализовать именно средствами Wi‑Fi.

  6. Экономическая эффективность. Разумеется, мы не хотим, чтобы опорная сеть стоила слишком дорого.

Wi-Fi в Яндексе 

Мы предъявляем к Wi‑Fi и к производителям Wi‑Fi‑точек доступа достаточно серьезные требования. Большинство из них связаны с самими Wi‑Fi‑точками доступа и с их умением управлять радиоэфиром. Есть несколько особенностей, которые для нас важны в контексте опорной сети для Wi‑Fi. 

Первое и самое главное — это прямая L2-связность между пользователем, подключившимся к Wi‑Fi‑точке доступа, и файрволом. Это необходимо для точного определения профиля пользователя и корректного применения к нему подходящих фильтров. Файрволы в Яндексе — одноюнитовые FreeBSD‑серверы по концепции «всё в одном». На них работают DNS, DHCP, Radius, Firewall. Мы их ласково называем «рыбками». Рыбов у нас много, но мы их не продаём, только показываем. 

При этом есть ещё одна важная особенность: нам важна прямая L2-связность между различными Wi‑Fi‑точками доступа — и вот почему. 

Обычно для управления пользовательским трафиком используют два подхода. 

Сentral switching. Точка доступа берёт пользовательский трафик, оборачивает его в CAPWAP‑туннель и отправляет контроллеру. Тот распаковывает его и помещает в пользовательскую подсеть. 

Local switching, когда точка доступа берёт трафик пользователя и перекладывает его в проводную сеть. 

Мы в Яндексе используем local switching. У нас довольно много небольших офисов, распределённых по всей России, и ставить в каждый из них выделенный Wi‑Fi‑контроллер было бы экономически нецелесообразно. Направлять пользовательский трафик через CAPWAP‑туннель до одной локации или дата‑центра тоже избыточно, потому что на каждой локации мы ставим «рыбки» — наши файрволы, которые могут фильтровать пользовательский трафик. 

А зачем нам вообще выделенный Wi‑Fi‑контроллер? Мы много раз задавали этот вопрос, и ответ был всегда один: он в большинстве случаев не нужен. Но как же мы тогда управляем радиоресурсами, распределяем каналы между точками, и отвечаем за роуминг пользователей? 

Кластерная архитектура Wi-Fi 

Существует такой подход, как кластерная архитектура. Мы берём несколько Wi‑Fi‑точек доступа, объединяем их в группу. Они сами договариваются между собой и определяют лидера — главную точку доступа, которая выполняет роль виртуального Wi‑Fi‑контроллера и занимается распределением ресурсов. 

Мы считаем такой подход вполне рабочим. Есть большое количество вендоров, которые поддерживают эту архитектуру: называться она может по‑разному, но суть всегда одна. Благодаря её внедрению мы получаем достаточно высокую отказоустойчивость. Если вдруг наша точка доступа станет недоступна, то роль лидера возьмёт вторая точка, потом третья, четвертая, пятая и так далее, пока не останется одна точка доступа, которая будет Wi‑Fi‑контроллером сама для себя. 

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

Опорная сеть для Wi‑Fi и L2-связность

Для нашей Wi‑Fi сети нам нужна прямая L2-связность, а также связанность между Wi‑Fi‑точками доступа, и самое главное — выбран local switching. Мы хотим, чтобы пользователи при роуминге корректно попадали в свою же подсеть. Поэтому растягиваем пользовательскую подсеть на все Wi‑Fi‑точки доступа — другими словами, растягиваем L2. Это отлично работает на небольших локациях, неплохо работает на средних локациях. Но что делать, если офис у нас побольше? 

Яндекс сейчас строит новый офис. Он очень просторный и красивый, с большим количеством архитектурных изысков. Размер впечатляет: больше 250 000 м2 застройки, 20 этажей, рассчитан на 15 000 пользователей. Всё это будет обслуживаться тремя с половиной тысячами Wi‑Fi‑точек доступа, а мы хотим использовать там кластерную архитектуру и local switching. 

Пользователям, шагающим по коридорам, идущим между этажами по лестнице, важно оставаться в своей конференции и продолжать обсуждение. Возьмём пользовательскую подсеть и растянем её на все Wi‑Fi‑точки доступа на всё здание. План отличный, надёжный. Что же может пойти не так?

Например, может случиться широковещательный шторм. Он сложен тем, что, во‑первых, тяжело обнаружить возникшую петлю, нужно много ресурсов для понимания, где он зародился, и поиска проблемы. Во‑вторых, некоторые устройства, в том числе пользовательские, не могут прийти в себя после шторма, их требуется перезагружать. Поэтому для борьбы с широковещательным штормом приходится придумывать определенные приспособления, например, шторм‑контроль. 

Допустим, мы настроили нашу сеть и везде добавили шторм‑контроль. В пятницу вечером, собираясь домой к семье, решили напоследок взглянуть на экран мониторинга и увидели: шторм‑контроль отстрелил половину всех линков, а некоторые устройства и вовсе недоступны. Остаётся только задуматься, насколько удачные и хорошие выходные нас ожидают.

Мы такого не хотим. Какие способы с этим бороться: 

  1. Надеяться, что шторм не проявит себя в вашу смену (самый простой вариант).

  2. Использовать выделенный Wi‑Fi‑контроллер и central switching. В этом случае мы должны отказаться от кластерной архитектуры. 

  3. Сегментировать или изолировать сегменты друг от друга.

Давайте рассмотрим каждый из вариантов немного подробнее. 

Предположим, мы смогли убедить себя не смотреть на мониторинг по пятницам. Хорошо. Но большой L2-домен всё равно нужно поделить, потому что пользовательские устройства совершенно точно не обрадуются, когда увидят 15 тысяч соседей. 

Чтобы минимизировать влияние на пользователя, приходится использовать VLAN‑пулинг. Это такой подход, когда мы берём пользователей и равномерно распределяем их по пользовательским подсетям, тем самым уменьшая влияние друг на друга. 

Однако от корневой проблемы больших доменов это не спасает. Если появится шторм, он зацепит абсолютно всё. Потому такое решение не годится. 

Рассмотрим второй вариант — использование выделенных Wi‑Fi‑контроллеров и central switching. Он наиболее приоритетный и часто всеми используемый. Но несмотря на простоту и понятность, и у него есть свои недостатки. 

  • Мы замыкаемся на контроллеры, которые используем, это единая точка отказа. Если вдруг с контроллером что‑то случится, это зацепит всех пользователей. А контроллеры могут перестать быть доступны, у них могут быть баги в прошивке и ошибки софта. 

  • Ещё один недостаток в том, что это значительно удорожает интеграцию Wi‑Fi‑сети в целом. Мы должны купить не просто железо в виде Wi‑Fi‑точек доступа, а ещё и лицензии к ним, выделенные Wi‑Fi‑контроллеры, которые должны быть производительными. Возможно, нам понадобится не одна и не две пары контроллеров. Всё это значительно увеличивает стоимость. 

  • Если мы решаем идти в сторону выделенных Wi‑Fi‑контроллеров, мы замыкаем себя на одном производителе. Когда нам потребуется добавить 10 Wi‑Fi‑точек доступа, нужно позаботиться о лицензировании. Сегодня мы смогли купить лицензии, чтобы добавить их, а завтра, может быть, и не сможем. 

  • Некоторые производители делают хорошее железо, но в принципе не могут реализовывать central switching. У них нет выделенных Wi‑Fi‑контроллеров. 

Третий вариант решения — это понятная всем технология изоляции портов. Мы просто запрещаем портам взаимодействовать друг с другом. Оказалось, что этот дизайн очень негибкий, и в таком случае мы должны строить свою сеть вокруг него. Что делать, если некоторым пользователям понадобится L2-доступ друг к другу?

У нас есть разработчики, которые создают умные устройства, им нужен L2-доступ. Как быть в этом случае, непонятно. Поэтому этот вариант мы тоже отмели. 

И тут мы задумались, что такое роуминг и как он выглядит со стороны сети. 

Роуминг — это переход пользователя от одной точки доступа к другой. MAC‑адрес светился сначала на одном коммутаторе, потом начал светиться на втором коммутаторе. Это очень похоже на миграцию виртуальных машин в дата‑центрах между гипервизорами. Только в случае с Wi‑Fi скорость миграции должна быть значительно выше. 

Плюсы и минусы VxLAN по сравнению с L2

Мы посмотрели, какие технологии используются в дата‑центрах, и остановились на технологии VxLAN. Это дало нам довольно много бонусов в гибкости построения туннелей: мы смогли их сегментировать так, как нам нужно. При этом можно включить Equal Cost Multipass, тем самым полноценно использовать всю сеть и убрать простаивающие линки. 

Конечно, у VxLAN есть и минусы. Увеличивается сложность сети. Вместо обычного стандартного spanning tree и L2-VLAN у нас появляется L3 как underlay (опорный уровень), вместе с протоколами динамической маршрутизации. Также появляется и overlay (уровень над опорным) — VxLAN с его растянутыми туннелями. 

Мы рискнули попробовать такую схему. В первую очередь решили определиться с тем, какой у нас будет андерлей‑сеть. Выбрали обычную классическую двухуровневую CLOS‑топологию со spine и leaf. 

Мы договорились использовать протокол BGP как наиболее универсальный. Каждое устройство имеет свою автономную систему, все друг с другом взаимодействуют, все лупбэки коммутаторов известны всем. 

Далее, поверх андерлея, мы решили попробовать BGP EVPN, чтобы посмотреть, как это будет работать, и как использование технологии VxLAN повлияет на роуминг. Мы собрали самый простой вариант, когда не используется никаких политик Route Target: ни на импорт, ни на экспорт (RT‑import/export). Все друг с другом обмениваются информацией по BGP EVPN. Все ко всем строят туннели (full mesh). 

Также решили посмотреть, как работает роуминг. Оказалось, что вполне корректно. Пользователи успешно мигрируют от точки доступа к точке доступа. Никаких проблем и жалоб мы не увидели. Так пришло время для следующего этапа: мы захотели убрать туннель соединяющий два нижних leaf, чтобы пользователи перестали друг с другом взаимодействовать. 

Как устроен роуминг 

Давайте немного подробнее разберем, как работает роуминг или MAC‑learning в BGP EVPN. Когда пользователь впервые подключается к Wi‑Fi‑точке доступа, его MAC‑адрес становится известен первому коммутатору. Он видит MAC‑адрес в первый раз, и всем говорит: «Друзья, пользователь находится здесь, у меня». Эта информация разлетается ко всем, все с этим соглашаются, всё хорошо. Так получается, что у нас один маршрут к пользователю. 

Далее пользователь мигрирует и переходит к следующей точке доступа. Второй коммутатор видит его MAC‑адрес, и знает, что этот пользователь раньше был где‑то в другом месте, а значит перешел к нам. Второй коммутатор отправляет BGP‑анонс, что пользователь не просто здесь, а что он именно перешёл сюда. Добавляет extended‑атрибут MAC Mobility, в котором увеличивает счетчик на единицу. Этот пакет доходит в том числе и до первого коммутатора. 

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

Теперь предположим, что мы возьмём и уберём туннель между двумя нижними leaf, запретим им взаимодействовать друг с другом по BGP EVPN. Настроим политики Route Target. 

Когда пользователь впервые подключается к Wi‑Fi‑точке доступа, первый коммутатор видит его MAC‑адрес и всем сообщает, что пользователь здесь. 

Эта информация разлетается ко всем, кроме второго leaf. Пользователь переходит дальше, попадает в роуминг. Его MAC‑адрес появляется на коммутаторе номер 2, на leaf номер 2. Второй leaf видит этот MAC‑адрес впервые и никакого расширенного атрибута не добавляет. Он просто всем говорит, что пользователь здесь. 

Конечно же, эта информация также не долетает до первого leaf. В итоге получается интересная ситуация, когда у нас в один момент времени есть два маршрута к одному и тому же пользователю, но с разными точками назначения. 

Мы решили попробовать использовать статические VxLAN‑туннели, но нам не нравится, как это делает BGP EVPN. И поскольку мы в Яндексе любим создавать новые инструменты и выкладывать их в опенсорс, то решили попробовать сами собрать такую же конструкцию, но на статических VxLAN‑туннелях. Так получили все бонусы от VxLAN и лишились недостатков, которые приносит нам BGP EVPN.

Как устроены статические VxLAN‑туннели

Очень важное отличие при использовании статических VxLAN‑туннелей по сравнению с BGP и EVPN: MAC‑адреса пользователей изучаются динамически. Нет никакого оверлея, нет никакого контроля, который рассылает информацию о MAC‑адресах. 

Тут всё работает просто: пользователь подключается к коммутатору, к Wi‑Fi‑точке доступа. Коммутатор видит MAC‑адрес. Пользователь отправляет первый пакет. Как правило, это первый широковещательный пакет. Дальше с помощью механизма Ingress Replication Leaf 1 рассылает этот пакет в сторону Edge Leaf 1 и Edge Leaf 2. Оба этих leaf теперь знают, как добраться до MAC‑адреса. 

Когда пользователь мигрирует, всё работает точно так же. Он отправляет свой первый пакет, который доходит до обоих edge‑leaf (он же бордер‑leaf), и каждый Edge Leaf просто меняет таблицу, где находится MAC‑адрес пользователя. 

В итоге мы смогли ограничить взаимодействие пользователей друг с другом. На картинке ниже два скриншота, которые сделаны примерно в одинаковых ситуациях в одно время. Это дамп широковещательного трафика. Подключившись к Wi‑Fi‑точке доступа, в первом случае мы не включаем изоляцию, во втором случае изоляцию включаем. 

Видно, что радиоэфир стал значительно чище, и до нас не долетают широковещательные пакеты, которые предназначены для других пользователей, прилетает только то, что нужно. 

Это позволило масштабировать нашу фабрику и всю сеть. Ведь в каждом leaf нам нужно построить только то количество туннелей, которое необходимо для него. Допустим, к бордер‑leaf и, может быть, друг с другом. 

Производительность фабрики и то, насколько большой она может быть, регламентируется устройствами edge‑leaf. Ведь они должны строить VxLAN‑туннели к каждому leaf и каждому коммутатору доступа. 

Для примера посмотрим документацию оборудования, которое мы используем. Производителем заявлен, что поддерживается до 2000 VxLAN‑туннелей. На всякий случай поделим эту цифру на два. И можем считать, что масштабирование может достигать 1000 leaf‑коммутаторов. В каждый leaf‑коммутатор можем подключить по 24 точки доступа. Получается: суммарно в эту фабрику мы можем завести больше 20 тысяч точек доступа. 

За счёт чего появляется такая возможность масштабирования? Давайте взглянем на сеть с точки зрения пользователя. 

Посмотрим, какое количество MAC‑адресов видит User 1 в своей сети: он видит файрволы, VRRP‑адрес, который используют файрволы, и, возможно, видит других клиентов, подключенных к той же самой Wi‑Fi‑точке доступа. 

К сожалению, связанность между пользователями, подключенными к одной и той же Wi‑Fi точке доступа, нельзя оборвать с помощью опорной сети для Wi‑Fi. Это должна сделать сама точка доступа. На схеме в фиолетовом прямоугольнике пользователи видят только то, что предназначено для них. 

Теперь переключимся на то, как сеть видят Wi‑Fi‑точки доступа. 

Мы помним, что хотим использовать кластерную архитектуру, а значит, собираем точки доступа в группу и растягиваем L2 между всеми Wi‑Fi‑точками доступа отдельной уникальной группы. Особенность в том, что мы этот жёлтый квадрат, показанный пунктиром, можем масштабировать так, как нам нужно. Если хотим, мы можем загнать туда одну точку доступа или 5, или 10, или 20 — то количество точек доступа, которое поддерживается в кластерной архитектуре вендора. 

Давайте теперь взглянем, как сеть выглядит со стороны коммутаторов доступа, или leaf. Leaf видят вышестоящие spine, коммутаторы, условно говоря, распределение, и общаются с ним исключительно по L3. Здесь уже нет никаких MAC‑адресов. Дальше идёт только L3, только BGP. При этом на каждом из этих уровней, изображённых на картинке, горизонтальных связей никаких нет. 

Группа коммутаторов leaf, подключенных к двум spine, обычно называется подом или строительным кубиком. Мы можем подключать дополнительные кубики, и они влиять на существующую сеть никак не будут. 

Эту конструкцию можно масштабировать дальше — подключить эти spine к вышестоящим коммутаторам. Обычно они называются spine второго уровня. Но так как нам не нужно здесь горизонтального трафика, он у нас строго вертикальный, то мы просто ставим туда устройство Edge Leaf, которые тоже достаточно производительные. 

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

Здесь есть важный нюанс: мы используем статические VxLAN‑туннели, а чтобы собрать всю эту архитектуру на них, потребуется довольно большое количество конфигураций на устройствах. 

В Яндексе для этого есть свой фреймворк Annet, который разработан в компании и выложен абсолютно бесплатно в опенсорс. Этот фреймворк позволяет генерировать конфигурацию и смотреть diff — разницу между целевой и текущей версиями, а также снулять конфигурацию. При этом в Telegram можно получить поддержку комьюнити и задать свои вопросы. Есть также лабораторные работы, которые позволяют погрузиться в этот инструмент. 

Annet для создания VxLAN-туннелей

Предположим, у нас есть Annet и некая точка истины (SoT, source of truth), например, Netbox. Далее в рамках Annet мы должны описать mesh‑модель. Mesh‑модель — это алгоритм, по которому мы собираем пары устройств. Ведь туннель — это пара, точка А и точка Б. 

Мы используем точку истины и mesh‑модель, получаем пары. Дальше в Annet можно сформировать генератор для VxLAN‑туннелей — шаблон конфигурации. Берём пару устройств и шаблон, получаем конфигурацию для каждого отдельного устройства. После этого можно попросить Annet сходить на целевое устройство, посмотреть, какой там конфиг, взять текущее состояние, взять целевое состояние и сформировать патч. Патч — это набор команд, которые необходимо применить для того, чтобы привести состояние оборудования в целевой вид. 

Annet тоже может это сделать: сходить на устройство, снулить diff и привести всё к целевому виду. 

Можно рассмотреть пример. Сеть, состоящая из двух edge‑leaf. Предположим, мы завели их в Netbox в точку истины, описали mesh‑модель, так как мы хотим, сформировали генераторы для VxLAN‑туннелей и получили вот такой простой конфиг. 

Этот пример приведён для вендора Arista. VxLAN‑туннели строятся буквально несколькими строками. У других производителей схема примерно такая же: нужно не очень много конфигураций, чтобы поднять VxLAN‑туннели. 

Wi-Fi over VxLAN: результаты 

Нам удалось соблюсти все важные условия:

  • Изоляция пользователей друг от друга. Это не только повышает безопасность нашей сети, но и улучшает использование радиоэфира, который становится чище. При этом изоляция позволяет нам масштабировать нашу сеть до действительно больших значений. 

  • Мультивендорность: технология статических VXLAN‑туннелей поддерживается многими вендорами, в том числе и отечественными. Wi‑Fi может быть выбран у любого вендора. Если потребуется, мы можем взять нашу кластерную группу и заменить вендора на другого. 

  • Стоимость. В нашем случае так получилось, что все офисные коммутаторы, которые мы уже использовали, поддерживают статические VxLAN‑туннели из коробки. Никаких дополнительных лицензий не потребовалось. Чтобы один из офисов перевести на Wi‑Fi с VxLAN, потребовалось использовать пару дополнительных оптоволокон и привести андерлей в целевой вид. Ещё добавить пару SFP‑модулей. 

Конечно, никакого spanning tree мы не используем. Всё это функционирует поверх L3. Работает ECMP. Мы используем нашу сеть на полную катушку. При этом у некоторых вендоров есть возможность включить BUM suppression, когда лишний широковещательный трафик просто отсеивается. Это дополнительная защита от возможных петель и штормов. 

Мы начали применять этот подход относительно недавно, год с небольшим назад, и на текущий момент перевезли 70 коммутаторов под VxLAN‑фабрику. Всего одномоментно обслуживается фабрикой чуть больше 4000 пользователей. Теперь это наш основной дизайн: все новые офисы мы стараемся делать по такому принципу. 

В заключение основные ссылки: