1. Статьи
Заметки пользователей
07.12.2009 10:37
PDF
108230
8

VLAN на пользователя: архитектура и альтернативы

Авторы: Антон Марченко (сетевой архитектор) и Андрей Захаров (менеджер по работе с клиентами), специалисты компании BCC по направлению Городские операторские сети, www.metroethernet.ru.

Статья публикуется в рамках конкурса "Формула связи".

На протяжении уже довольно долгого времени одной из наиболее обсуждаемых тем при построении городских Ethernet-сетей является возможность использования в них архитектуры «VLAN на пользователя» или выделение каждого абонента в отдельный широковещательный сегмент. В данной статье мы оценим сильные и слабые стороны данной архитектуры, рассмотрим варианты её реализации, а также представим альтернативное решение на базе функций Private VLAN и Local Proxy ARP.

Для того, чтобы понять для чего нужна архитектура «VLAN на пользователя», вначале рассмотрим традиционную и наиболее простую архитектуру с общим VLAN, когда все устройства сети находятся в одном широковещательном домене (см. рис.1)

VLAN на пользователя: архитектура и альтернативы

Рисунок 1. Архитектура с общим VLAN

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

Основные недостатки архитектуры с общим VLAN:

  1. Изоляция абонентов на втором уровне отсутствует (Layer2), что создает опасность сетевых атак: подмена абонентом своего IP- или MAC-адреса, установка несанкционированного DHCP-сервера, ARP Spoofing, переполнение таблицы MAC-адресов коммутатора.

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

Для решения первой проблемы используются управляемые коммутаторы доступа с поддержкой функций безопасности (DHCP Snooping, IP Source Guard, Port Security, Dynamic ARP Inspection). Решение второй проблемы с точкой контроля локального трафика требует принципиальной перестройки архитектуры сети. И одним из получивших применение способов стал переход на архитектуру «VLAN на пользователя».

Таблица 1 – Сравнение архитектур «Общий VLAN» и «VLAN на пользователя»

 

Общий VLAN

VLAN на пользователя

Контроль локального трафика*

Ограниченный

Полный

Количество точек контроля трафика

Большое

Малое

Путь локального трафика**

Оптимальный

Неоптимальный

«Паразитный» широковещательный трафик***

Есть

Нет

Защита от типовых атак

Обеспечивается функциями на коммутаторе доступа

Обеспечивается архитектурой

Сложность реализации

Ниже

Выше

 

* Контроль трафика требуется для гибкого управления межабонентским трафиком, например, для блокировки доступа к локальным ресурсам сети при отрицательном балансе

** Необходимость прохождения локального трафика через точку контроля ведет к удлинению пути трафика между абонентами, что может увеличить нагрузку на каналы

*** При масштабировании сети широковещательный трафик создает ощутимую нагрузку на каналы связи и абонентские устройства

Архитектура «VLAN на пользователя», как следует из названия, подразумевает выделение для каждого абонента своего собственного VLAN.

Рассмотрим вариант реализации такой архитектуры, предлагаемый ведущими производителями - централизованную модель. В ней точкой консолидации всего абонентского трафика является устройство BRAS – Broadband Remote Access Server (см. рис.2).

VLAN на пользователя: архитектура и альтернативы

Рисунок 2. Централизованная модель VLAN на пользователя

Однако при рассмотрении такой модели возникает вопрос, как терминировать на одном устройстве всех абонентов в сети, если согласно стандарту IEEE 802.1q под номер VLAN выделено всего 12 бит (максимум 4096 значений). В этом случае при большом количестве абонентов решением является использование технологии двойного тегирования пакетов (Q-in-Q) и их терминация на BRAS.

К преимуществам централизованной модели так же можно отнести и единую точку контроля как Интернет- так и локального трафика. Это позволяет гибко управлять качеством обслуживания и полосой пропускания для каждого абонента. Также данная архитектура обеспечивает изоляцию абонентов на втором уровне, что решает большинство проблем безопасности, рассмотренных выше. Главным недостатком становится необходимость в производительном и как следствие достаточно дорогом BRAS.

Следующим вариантом является компромиссная децентрализованная модель, которая обеспечивает обработку Интернет-трафика на BRAS, а обмен локальным трафиком производится на Layer3-коммутаторах. Тем самым удается снизить нагрузку и требования по производительности к BRAS (см. рис.3).

VLAN на пользователя: архитектура и альтернативы

Рисунок 3. Децентрализованная модель VLAN на пользователя

В чем же основные достоинства децентрализованной модели? Во-первых, как и в централизованной сохраняется изоляция абонентов на втором уровне, тем самым решаются проблемы безопасности. Во-вторых, точками контроля локального трафика теперь являются коммутаторы агрегации, количество которых по сравнению с коммутаторами доступа в сети значительно меньше и они более унифицированы с точки зрения моделей оборудования. В-третьих, локальный трафик теперь не обрабатывается BRAS.

Недостатки децентрализованной модели:

  • Ограничение в 4096 VLAN на каждый коммутатор агрегации;

  • Неэффективное использование адресного пространства (может быть решено использованием проприетарной функции IP Unnumbered on SVI на коммутаторах Cisco);

  • Необходимость ручной конфигурации большого количества VLAN-интерфейсов на коммутаторах агрегации;

  • Индивидуальная конфигурация на каждом коммутаторе доступа.

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

Итак, изучив существующие подходы к построению архитектуры операторских Ethernet-сетей, в ходе реализации одного из недавних проектов по построению сети MetroEthernet, мы задались вопросом: Возможно ли найти альтернативный подход и получить архитектуру по функциональности схожую с децентрализованной моделью, но лишенную ее недостатков? Таким образом, была поставлена задача - обеспечить безопасность и сохранить возможность контроля локального трафика на Layer3-коммутаторах агрегации, но при этом избежать создания большого числа VLAN-интерфейсов, и так же максимально унифицировать конфигурацию коммутаторов доступа.

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

Во-первых, необходимо изолировать абонентские порты на коммутаторах доступа в рамках одного VLAN и разрешить прохождение трафика из абонентских портов только в uplink-порт, подключенный к вышестоящему коммутатору. Данная функция реализована во многих моделях коммутаторов доступа и имеет различные названия в зависимости от производителя: Private VLAN, Protected port, Traffic Segmentation.

Во-вторых, чтобы трафик между любыми двумя абонентами в рамках одного VLAN всегда проходил через коммутатор агрегации, необходимо, чтобы он отвечал на все ARP запросы внутри этого VLAN от своего имени. Такая функция носит название Local Proxy ARP.

Таким образом, мы получили сегментирование общего VLAN в коммутаторах доступа на отдельные широковещательные домены с помощью функции Private VLAN, а маршрутизацию трафика между этими доменами реализовали на коммутаторах агрегации с помощью Local Proxy ARP. Наглядно схема решения изображена на рис.4.

VLAN на пользователя: архитектура и альтернативы

Рисунок 4. Архитектура с использованием Private VLAN и Local Proxy ARP

Контроль локального трафика в данном случае осуществляется на коммутаторе агрегации с помощью списков доступа VLAN ACL.

Задача обеспечения безопасности решается аналогично схеме с общим VLAN – включением на коммутаторах доступа функций DHCP Snooping, Port Security, IP Source Guard и Dynamic ARP Inspection.

Проблема с «паразитным» широковещательным трафиком отсутствует, так как каждый абонент находится в собственном изолированном широковещательном домене. Широковещательные пакеты доходят только до коммутатора агрегации и не передаются остальным абонентам внутри общего VLAN.

В результате получилась архитектура по функциональным возможностям аналогичная децентрализованной схеме с VLAN на пользователя, но избавленная от её недостатков. Так как все пользователи находятся в одном VLAN, то конфигурация коммутаторов доступа упрощается и становится унифицированной. Конфигурация коммутаторов агрегации также упрощается за счет необходимости только в одном VLAN-интерфейсе.

Таблица 2 – Сравнение архитектур «PrivateVLAN + Local Proxy ARP» и «VLAN на пользователя»

 

PrivateVLAN +

Local Proxy ARP

VLAN на пользователя

Контроль локального трафика

Полный

Полный

Количество точек контроля трафика

Малое

Малое

«Паразитный» широковещательный трафик

Нет

Нет

Защита от типовых атак

Обеспечивается функциями на коммутаторе доступа

Обеспечивается архитектурой

Сложность реализации

Ниже

Выше

Конфигурация коммутаторов доступа

Унифицированная

Индивидуальная

Использование адресного пространства

Эффективное

Неэффективное

Представленная архитектура на базе функций PrivateVLAN + Local Proxy ARP была успешно протестирована и внедрена в реальной сети MetroEthernet, об опыте построения и технических деталях которой мы продолжим рассказ в следующей статье.

8 комментариев
Оставлять комментарии могут только авторизованные пользователи
Robot_NagNews
Robot_NagNews

Материал:

На протяжении уже довольно долгого времени одной из наиболее обсуждаемых тем при построении городских Ethernet-сетей является возможность использования в них архитектуры «VLAN на пользователя» или выделение каждого абонента в отдельный широковещательный сегмент.

 

Полный текст

ingress
ingress

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

1.чтобы включить на данном решении ipv6, свич должен ещё и быть ipv6 ready, в cvlan ipv6 должен быть только роутер(BRAS), никаких relay и аналогов opt82 не надо, ибо абонент однозначно детерминирован интерфейсом на шлюзе.

2.в схеме с shared vlan на свиче используется больше софтовых фич коммутатора(трафик который копируется на процессор) типа DHCP/DHCPv6 Relay, ND/mld snooping, в схеме с cvlan используется только один IGMP snooping.

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

 

во имя метро, езернета и триплплея - ресет!

DyadyaGenya
DyadyaGenya

а такой вопрос, если на агрегации стоят свичи не поддерживающие Local Proxy Arp, можно ли те ми же самыми Private Vlan пробросить трафик до роутера или свича который понимает локал прокси арп, ну или настроить скажем на роутере подобную штуку. просто уже стоят свичи, и менять их все сразу было бы накладно, хотелось бы плавно от них избавляться, ну или как то переносить в другое место сети

и кстати, если такая ситуация, кое где стоят за л2 свичами тупые 8 портовые, просто как расширение, иногда некогда и не зачем ставить свич на 48 портов или второй л2 на 24 порта, будет ли работать такая схема? нужно ли для неё что то дополнительно настраивать?

tawer
tawer

и такой вопрос, в телесине, в частности, реально ли завести несколько портов в private vlan и добавить туда ip int и организовать local proxy arp в рамках одного свитча?

andryas
andryas

Вопрос ipv6 как-то слабо раскрыт, особенно в схеме с shared vlan. ARP-то нетуть :)

MATPOC
MATPOC
11 часов назад, andryas сказал:

Вопрос ipv6 как-то слабо раскрыт, особенно в схеме с shared vlan. ARP-то нетуть :)

Нефиг некропостинги реанимировать :) Обычно так только новореги себя ведут.

andryas
andryas
52 minutes ago, MATPOC said:

Нефиг некропостинги реанимировать :)

Это не я, это прежний оратор, сбежавший куда-то, вместе со своим постом.

vodz
vodz

Да какой там оратор и новорег. Обычный спамер же был.

БОЛЬШЕ МАТЕРИЛОВ ПО ТЕМЕ
Плинт-тестер своими руками
Операторы связи нередко применяют в строительстве многожильные кабели (10-, 25- ... парники). Иногда требуется проверить кабель на замыкание, обрыв и порядок чередования жил. Бывает также, что различить жилы по маркировке трудно или невозможно. В таких случаях прозванивать вручную по две жилы долго и неудобно, поскольку число возможных вариантов велико.
04.12.2009 15:35
44337
26
Введение в договороведение
Сложно отыскать более употребительный юридический термин, чем понятие «договор». Общеупотребительность лишь размывает значение термина, придавая ему жаргонный характер. Не избежал этой нелегкой судьбы и «договор»: интуитивное представление о договоре обычно оказывается неправильным, но это выявляется только при возникновении спора, да и то, не всегда.
01.12.2009 23:28
22951
16
Подсчет и анализ сетевого трафика
Статья рассматривает сбор данных с маршрутизаторов Cisco для тарификации в автоматизированной системе расчетов, дает советы по исключению паразитного трафика при «помегабайтном» учете, а также проводит разбор и анализ трафика средствами flow-tools и rrdtools.
01.12.2009 11:55
56755
32
DDoS-атаки и как от них защищаться. Систематизация мирового и российского опыта
Основные принципы защиты от DDoS атак, история их развития в последнее десятилетие, и ситуация в настоящее время.
29.11.2009 22:00
59818
24
Свежий взгляд на PLC на примере решений компании Corinex
О технологии PLC так или иначе слышали многие, однако о реальных ее возможностях осведомлены лишь некоторые специалисты. Отчасти это связано с информационной политикой производителей и невнятным маркетингом, отчасти виноваты болезни роста, поскольку первая и вторая версия стандарта работали не так хорошо, как хотелось бы. В этом обзоре представлен свежий взгляд на возможности этой интересной технологии.
27.11.2009 11:58
63898
51