Кратко

  • RFC 3069 позволял разным клиентским VLAN совместно использовать IPv4-подсеть и шлюз, не объединяя их широковещательные домены второго уровня.
  • Узел в пределах того же префикса сначала использует ARP, поэтому посредником становится маршрутизатор super-VLAN. Одна маска не доказывает ни соседство, ни право доступа.

Меньше адресов — больше посредничества

Расчёт адресов выглядел убедительно. В примере RFC три клиента рассчитывали на шестнадцать узлов каждый. Раздельные подсети занимали 28 адресов с учётом сетевого адреса, направленного широковещания, шлюза и округления до степени двойки. Схеме RFC 3069 хватало девятнадцати: три клиентских sub-VLAN использовали общие 1.1.1.0/24 и шлюз 1.1.1.1, но диапазоны узлов не пересекались. Свободный адрес одного диапазона можно было передать другому клиенту без перенумерации первого.

Экономия не превращала клиентов в соседей второго уровня. Каждый sub-VLAN оставался отдельным широковещательным доменом. При этом узлы использовали длину префикса super-VLAN. Обычная логика IP считала адрес внутри 1.1.1.0/24 локальным и запускала ARP, вместо того чтобы передать пакет шлюзу по умолчанию. ARP разрешает адрес канального уровня в локальной сети; он не объединяет изолированные широковещательные домены.

Недостающий переход обеспечивал маршрутизатор super-VLAN. RFC 3069 допускает функцию, похожую на Proxy ARP: маршрутизатор отвечает на запрос об адресе в другом sub-VLAN, принимает кадр и пересылает пакет. Для узла цель выглядела соседом. В системе пересылки посредником был маршрутизатор. Префикс описывал адресное отношение, а не физический факт или связь на втором уровне.

За кажущейся простотой стоит операционное состояние. Маршрутизатор должен знать, какому sub-VLAN принадлежит адрес, решать, вправе ли отправитель использовать указанный исходный адрес, согласованно отвечать на ARP и пересылать данные по ожидаемому пути. Правдоподобная маска или успешный ARP-ответ не доказывают актуальность и авторизацию привязки адреса к VLAN. RFC рекомендует закреплённые диапазоны адресов: отбрасывать IP- и ARP-пакеты, пришедшие из sub-VLAN с источником, не выделенным этому сегменту; событие можно записывать. Защита зависит от локальных данных о назначениях и привязках.

Некоторые привычные функции подсети больше не соответствуют одному широковещательному домену. RFC 3069 не поддерживает направленное широковещание: адрес из одних битов не может одновременно обозначать несколько изолированных доменов второго уровня. Для multicast также нужна особая обработка; маршрутизатору могут понадобиться состояния, похожие на маршруты к отдельным узлам, чтобы проверки RPF работали между сегментами. Позднее RFC 4562 описал трудности репликации multicast при изоляции каждого клиента в отдельном VLAN и ограничение в 4096 VLAN для сетей широкополосного доступа.

Экономия адресов не устранила эксплуатационные затраты, а перенесла их в состояние маршрутизатора и работу сети.

Важно не преувеличивать доказательства. RFC 3069 — документ Informational, а не стандарт Интернета; детали реализации намеренно не задаются. В документе сказано, что Extreme Networks более года эксплуатировала рабочую реализацию в дата-центрах провайдеров. Это сообщение авторов RFC, не независимый обзор распространённости. О других поставщиках говорится лишь как о слухах. Широких измерений совместимости, частоты отказов или клиентских результатов нет.

Смотреть на пакет, а не только на маску

Если поток внутри одного префикса не работает, маска — лишь исходная подсказка. Нужно проверить ARP-запрос и ответ на входном sub-VLAN, исходный адрес, таблицу привязки адресов к VLAN на маршрутизаторе, решение proxy/ARP и результат пересылки. Для multicast важны состояние RPF и маршруты конкретного отправителя. Эти свидетельства показывают действия маршрутизатора в точке наблюдения, но сами по себе не доказывают успех приложения или изоляцию каждого пути доступа.

Источники