Резюме
- В первый день сеть JANOG58 зафиксировала 1 925 MAC-адресов на точках доступа, из которых около 1 580 были случайными, а число участников достигло 2 578.
- На этапе горячей подготовки, когда доступ был только у NOC, около 60 активных пользователей и примерно 120 конечных устройств оставили в истории 275 адресов — примерно в 2,3 раза больше, чем оценка числа устройств.
- Коммутаторы не приблизились к пределам своих таблиц MAC-адресов. Операционная проблема проявилась прежде всего в идентичности, политиках и телеметрии, а не в ёмкости пересылки.
- NOC также запустил экспериментальную схему VESPA поверх EVPN/VXLAN, но в опубликованных материалах нет сравнительных результатов производительности «до и после», которые доказывали бы, что площадке это требовалось.
Таблица MAC-адресов на JANOG58 не «взорвалась». Изменился смысл MAC-адреса.
Опубликованная после встречи Japan Network Operators' Group в Мацуяме презентация с полевыми результатами показывает, что сеть площадки сохраняла значительный запас коммутационной ёмкости. Она также показывает, почему свободная ёмкость может давать операторам ложное ощущение спокойствия, когда мобильные операционные системы ротируют частные адреса.
В первый день точки доступа обнаружили 1 925 MAC-адресов, а коммутаторы зафиксировали около 2 000. Из всех адресов на точках доступа примерно 1 580 — около 82 % — были случайными, а не глобально назначенными адресами. Встречу посетили 2 578 участников, однако эти цифры нельзя рассматривать как соотношение один к одному: не каждый участник обязательно подключался к Wi-Fi, а один человек мог иметь несколько устройств или появляться под несколькими адресами.
Новый результат важен, потому что операторы JANOG готовились к знакомой инженерной проблеме — заполнению таблицы. А измерили они учётную проблему, которая возникает гораздо раньше.
Ёмкость не была ограничением
Исходное предположение NOC было простым: 50 точек доступа, умноженные на 100 клиентов, дают потребность примерно в 5 000 адресов. Заявленные ёмкости коммутаторов были значительно больше. Использовавшийся в качестве шлюза уровня 3 коммутатор 7050SX3 поддерживал таблицу MAC-адресов на 160 000 записей; коммутаторы доступа 720XP и 710P заявлялись с 64 000 и 32 000 записей соответственно.
Этот запас позволил команде выбрать для площадки плоскую схему на уровне 2. В презентации с результатами прямо сказано, что рост числа адресов не дошёл до переполнения таблицы.
Это полезный отрицательный результат. Оператор, смотрящий только на главную цифру, мог бы купить более крупный коммутатор и ничего не решить. Ёмкость таблицы отвечает на вопрос, сколько записей пересылки может хранить устройство. Она не отвечает, по-прежнему ли запись соответствует стабильному устройству, следует ли политика за пользователем и остаётся ли вчерашний адрес полезным для диагностики сегодня.
Данные JANOG также не доказывают, что рандомизация вызвала перегрузки, потери пакетов или сбой. В презентации нет таких заявлений о производительности. Её ценность в том, что она показывает: единица наблюдения стала нестабильной, тогда как оборудование пересылки оставалось в комфортном режиме.
Одно устройство может оставить несколько операционных идентичностей
Более точное измерение было сделано до открытия конференции для всех участников. В период горячей подготовки, когда доступ был только у NOC, команда насчитала около 60 активных пользователей. Если предположить два конечных устройства на пользователя, получается оценка примерно в 120 устройств. Однако история точек доступа содержала 275 MAC-адресов — примерно в 2,3 раза больше этой оценки, и 245 из них были случайными.
Авторы предполагают, что переходы между SSID NOC, гостевой сети и OpenRoaming могли внести вклад. Это гипотеза, а не измеренное причинное разделение. Количество конечных устройств тоже является оценкой. Но направление ясно: историческое состояние адресов может расти быстрее, чем число физических клиентов.
Для операторов это сразу меняет несколько плоскостей контроля. Аутентификация и правила доступа на основе MAC-адресов могут терять непрерывность. Состояние DHCP и потребление адресов могут расти. Аналитика использования может считать адреса, а не людей или устройства. Специалист по реагированию на инциденты может обнаружить несколько короткоживущих идентификаторов для одного конечного устройства, что ослабляет связь между обращением пользователя, журналом точки доступа и таблицей коммутатора.
Рандомизация существует по уважительной причине защиты приватности: долговечный аппаратный идентификатор можно использовать для отслеживания устройства в разных беспроводных средах. Поэтому задача оператора не в том, чтобы отменить приватность, а в том, чтобы перестать использовать намеренно нестабильный идентификатор как постоянный ключ идентичности.
VESPA переносит то, где находится состояние уровня 2
NOC JANOG пошёл дальше измерений и запустил экспериментальный беспроводной маршрут на базе двух шлюзов VESPA, VPN уровня 2 на EVPN/VXLAN и точек доступа, представляющих Wi-Fi 6, 6E и 7.
Сопровождающая техническая презентация описывает VESPA — Virtual Ethernet Segment with Proxy ARP — как реализацию Arista, которая расширяет модель EVPN multihoming на Ethernet-сегменты, подключённые через туннели. Точки доступа выступают прокси уровня 2, а шлюзы хранят состояние адресов клиентов и используют общую идентичность набора шлюзов и виртуальную конечную точку туннеля.
Лежащие в основе идеи не произвольны. RFC 7432 определяет Ethernet-сегменты EVPN и мобильность MAC-адресов. RFC 9161 описывает, как прокси ARP и обнаружение соседей могут распространять привязки IP к MAC и уменьшать лавинную рассылку запросов разрешения адресов в больших широковещательных доменах.
Но саму VESPA не следует представлять как стандарт IETF, и данное испытание не доказывает, что JANOG58 нуждался в ней, чтобы избежать исчерпания. Опубликованные цифры показывают обратное: сырая ёмкость MAC-адресов была в избытке. Эксперимент лучше понимать как проверку того, где должно храниться нестабильное состояние клиентов и как крупный сервис уровня 2 может оставаться работоспособным при росте сменяемости беспроводных идентичностей.
В открытых материалах нет сравнения «до и после» по потерям пакетов, задержке, нагрузке на плоскость управления, состоянию ARP или DHCP или времени диагностики. Без этих показателей испытание является операционным свидетельством, а не вердиктом о продукте.
Следующий ориентир — сменяемость, а не только размер таблицы
Следующий отчёт JANOG мог бы превратить этот полезный срез в более сильный операционный ориентир. Ему следует отделять одновременных клиентов от исторических адресов; фиксировать, как часто одно конечное устройство меняет идентификаторы; измерять аренды DHCP, записи ARP и загрузку процессора плоскости управления; а также сравнивать широковещательный трафик, задержку и частоту сбоев до и после внедрения прокси-схемы.
Закупки должны следовать той же логике. Максимальное число MAC-адресов коммутатора — необходимые данные о ёмкости, но их уже недостаточно. Покупателям также нужны средства управления хранением, интеграция идентичностей, поведение для каждого SSID, наблюдаемость изменений адресов и понятный режим отказа, когда состояние прокси устаревает.
Результат JANOG58 ценен именно потому, что опасного сбоя не произошло. Сеть не исчерпала пространство таблиц. Вместо этого он вскрыл проблему управления внутри сетевой эксплуатации: кого или что представляет адрес, как долго, и какая система отвечает за сохранение непрерывности, если адрес изначально создан изменяемым?