Ограничение широковещательного домена

[megahertz0]

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

На ней планируется wifi-сеть на ~200 точек UniFi. Хотелось бы, конечно, айронеты с контроллером, но цена там будет просто космической. Так что UniFi меншее из всех зол. Но вопрос главный не в этом. Необходимо, чтобы клиенты подключиться в сети в любой точке сети, так что везде одинаковый SSID. На этаж планирую каталисты 2960, все этажи будут связаны оптическим кольцом для повышения отказоустойчивости, агрегируемом на каталисте 3750G. Дальше трафик попадает в тазик с натом/шейпером и дальше попадает уже к нам в сетку. Менеджмент у точек вынесен в отдельный VLAN, с релеем на DHCP, в общем с этим сложностей нет. Но возникает вопрос с клиентским VLAN и широковещательным трафиком в нем. Решение в лоб с одним VLAN на всех клиентов все таки кажется не очень удачным.

Хотя внутри точек клиенты изолированы средствами самих точек, тем не менее клиенты на разных точках друг друга видят. Конечно, между точками можно обрезать широковещательный трафик ACLами, но все равно все не учтешь. Поэтому сижу и думаю над изоляцией клиентов. В идеале хочется, чтобы клиенты видели только шлюз, т.е. SVI на 3750. Но как этого достичь - хз. И опять же требование чтобы куча точек виделась как одна сеть.

Предполагаемый вариант 1 - switchport protected в сторону точек на доступе. Правда хз как работает на транковом порту (на точке 2 влана, менеджмент и клиенты). И опять же в предалах коммутатора клиенты видеть друг друга не будут, а между коммутаторами - пожалуйста.

Вариант 2 - private vlan. Но он есть только на L3 (3750, 3560 и выше). 3560 на доступ ставить имхо жирно, так что отпадает. И опять же проблема из п.1.

Вариант 3 - ip unnumbered на 3750 и vlan на точку. Имхо самый красивый вариант, но есть одно НО. Допустим на 3750 я подниму по SVI на точку (или этаж), сделаю ip unnumbered на лупбэк. Т.к. 3750 будет работать как dhcp-релей, то маршрут будет создаваться автоматом при получении клиентом адреса и на первый взгляд все хорошо. Но, к примеру, если случиться ситуация, когда клиент, переключится с одной точки на другую, которая терминируется на другом SVI, то связь у него сразу пропадет т.к. при роуминге клиент не переполучает адрес и маршрут в таблице маршрутизации циски останется таким, как будто клиент остался на предыдущей точке. Да и если и переполучит адрес, то неизвестно, что будет со старым маршрутом. Хотя вариант конечно красив и работал бы для статики или клиентов, которые не перемещаются по зданию.

 

В общем, хотелось бы услышать мнение по вышеперечисленным вариантам. Ну или еще какой-нибудь вариант.

[Negator]

На длинках есть traffic_segmentation аля private vlan. В случае с длинками на доступе я бы делал на нем.

[megahertz0]

На длинках есть traffic_segmentation аля private vlan. В случае с длинками на доступе я бы делал на нем.

 

Опять же, работает в пределах одного коммутатора?

[Negator]

Опять же, работает в пределах одного коммутатора?

Ну да

А кто мешает на коммутаторах выше настроить тоже сегментацию?

 

А на самом деле при корректной настройке ACL большие широковещательные домены не особо страшны.

Ну и требования у Вас взаимоисключающие:

Для корректной работы роуминга необходимо один броадкастовый домен, а он не подразумевает изоляции клиентов.

 

Кроме этого я не вижу необходимость в dhcp relay. Возможно что то можно придумать в схеме без релея.

[rdc]

В случае звезды вопрос полностью решится с помощью traffic_segmentation

В случае кольца - traffic_segmentation в пределах свича, и по влану на каждый свич.

[Saab95]

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

 

То же самое и с вланом для управления - не нужно гнать все в одном влане, так же следует разделять на несколько.

 

Но самое главное, сеть из 200 точек на UniFi не будет нормально работать и управлять всем этим барахлом будет очень и очень сложно.

[megahertz0]

Ну да

А кто мешает на коммутаторах выше настроить тоже сегментацию?

А на транковых портах traffic segmentation работает? Сейчас просто вспомнил, что циска как раз не допускает использование switchport pretected на транках. Интересно как у длинков?

[megahertz0]

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

А МТ прокачает 200 мбит НАТа? Ну или хотя бы отроутит? Честно говоря в микротиках не силен, в основном как CPE использовал.

 

То же самое и с вланом для управления - не нужно гнать все в одном влане, так же следует разделять на несколько.

А какой смысл? Там как раз из бродкаста только DHCP на точках и все.

 

Но самое главное, сеть из 200 точек на UniFi не будет нормально работать и управлять всем этим барахлом будет очень и очень сложно.

Как раз таки управлять будет удобно. Ну вебинтрефейс там, менюшки прикольные, AJAX и HTML5. Местным нравится, не то что какие-то белые буквы на черном фоне. Насчет засирания эфира, коллизий и интерференции - если мощность отрегулировать, то, думаю, части проблем избежать удастся. Да и территория огромная просто, экспоцентр, к примеру, это 4 этажа по 500 кв.м. Засрать, думаю, будет сложно. И к тому же основное требование к wifi - 2-4 мбит на клиента.

[Negator]

Но самое главное, сеть из 200 точек на UniFi не будет нормально работать и управлять всем этим барахлом будет очень и очень сложно.

там в очередной раз рекламируют микротики. ХЗ как с ними, но UniFi работает нормально.

Да и влана управления одного более чем достаточно.

 

А на транковых портах traffic segmentation работает?

в длинках работает 100%.

 

Правда хз как работает на транковом порту (на точке 2 влана, менеджмент и клиенты)

попробуйте настроить клиентов в native влан и включить switchport protected.

 

Я с цисками работал крайне мало, поэтому точнее не скажу.

[megahertz0]

попробуйте настроить клиентов в native влан и включить switchport protected.

Думаю что надо просто стенд собрать.

 

там в очередной раз рекламируют микротики. ХЗ как с ними, но UniFi работает нормально.

Я в курсе что Сааб95 и микротик - друзья на век ))). Без обид. Просто Сааб95 видимо имел в виду управление мощностью, noise floor и прочие ништяки МТ.

[Saab95]

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

А МТ прокачает 200 мбит НАТа? Ну или хотя бы отроутит? Честно говоря в микротиках не силен, в основном как CPE использовал.

 

Прокачает и 1000 мегабит, в зависимости от железки. На начальном этапе можно взять RB1100AHx2, свести все вланы на него и настроить бридж. Для отказоустойчивости и балансировки нагрузки ставите 2 железки, на одной настраиваете например подсеть 192.168.0.0/24, на второй 192.168.1.0/24, они будут выхватывать DHCP запросы и распределять между собой.

 

То же самое и с вланом для управления - не нужно гнать все в одном влане, так же следует разделять на несколько.

А какой смысл? Там как раз из бродкаста только DHCP на точках и все.

 

Если настроить влан на этаж, то если он (этаж) пропадет разом в мониторинге, вы будете знать где искать причину. А с одним большим у вас пол сети пропадет, как будете неисправность искать?

 

там в очередной раз рекламируют микротики. ХЗ как с ними, но UniFi работает нормально.

Я в курсе что Сааб95 и микротик - друзья на век ))). Без обид. Просто Сааб95 видимо имел в виду управление мощностью, noise floor и прочие ништяки МТ.

 

Просто вы не в курсе современных тенденций моды беспроводных точек, сейчас все делается легко и просто - щелк и готово!

 

[megahertz0]

Эмммм. Ну как сказать, заббикс, триггеры всякие. Карта сети там ещё есть и алерты с триггерами ещё. А если серьёзно, то у всех коммутаторов свой менеджмент влан со всякими такаксами, сислогами и snmp. Он терминируется на л3 свитче. Стандарт у нас такой внутрений. Все это подцепляется к заббиксу и прекрасно отслеживается с базы. Точки прекрасно мониторятся из фронтенда контроллера, а если им дать алиасы, то неисправности отслеживаются легко и просто.

 

Rb751 в люстре это жёстко однако.

[dsk]

А МТ прокачает 200 мбит НАТа? Ну или хотя бы отроутит?

 

CCR1016 легко.

А по сегментации, по идее вам должен помочь ip unnumbered poll.

[megahertz0]

А по сегментации, по идее вам должен помочь ip unnumbered poll.

Если я правильно понял, то polling просто с SVI рассылает ARP-запросы и если клиент отвечает, то создается обратный маршрут. Хорошо, а что тогда происходит с со старым маршрутом через предыдущий SVI?

[dmvy]

Расскажите пожалуйста, какими правилами в фаерволе можно ограничить общение интерфейсов в бридже между собой?