UNMS для EdgeMax против UniFi Controller для UniFi

UNMS для EdgeMax против UniFi Controller для UniFi, UniFi Network

sirozha

Guest

24.05.2017 19:19:00

Может кто-нибудь прокомментировать, как UNMS сравнивается с UniFi Controller по функционалу и возможностям? До сегодняшнего дня я не знал, что существует попытка внедрить централизованное решение с единым интерфейсом управления на базе контроллера для линейки продуктов EdgeMax, включая маршрутизаторы и коммутаторы EdgeMax. Я только что прочитал про UNMS и он меня заинтересовал.

Какое направление выбирает Ubiquiti, имея две продуктовые линейки — EdgeMax и UniFi — которые сильно пересекаются в части маршрутизации и коммутаторов, и у каждой из которых есть своё собственное централизованное решение с единым интерфейсом управления? Планируется ли, что роутеры и коммутаторы UniFi будут ориентированы на продвинутых пользователей и малый бизнес, а EdgeMax — на средний бизнес? Или Ubiquiti будет развивать эти две линии похожим образом, как Hyundai/Kia, когда непонятно, зачем вообще параллельно выпускаются две очень похожие продуктовые линейки вместо того, чтобы объединить их?

NYRican79

Guest

30.03.2018 03:53:00

Нет, я понимаю, что ты придумал обходной путь, и вполне логично, что ты решил реализовать управление трафиком на USG. Но, исходя из описания твоей сети, нет сомнений, что тебе бы очень помог L3 коммутатор. Потому что не весь трафик должен проходить через USG — часть из него может оставаться в широковещательной сети, но у тебя вся сеть транслируется через один гигабитный линк. Ты говоришь, что при маршрутизации появляется большая задержка — я с этим не согласен, нет никаких доказательств, что в L3 задержка больше, чем в L2. Первый пакет действительно проходит через таблицу маршрутизации, это верно, но после этого вся необходимая информация хранится в базе данных пересылки на коммутаторе. Это работает похожим образом с таблицей MAC-адресов, только вместо MAC там IP-адреса, так что трафик можно отправлять на полной скорости в L3-сети. Потери производительности при использовании L3 нет. С другой стороны, если у тебя роутер «через один порт» — а именно так у тебя и настроено — то я могу загрузить этот канал по полной и ухудшить производительность, и именно тогда придется внедрять управление трафиком. У меня EdgeSwitch, а точками доступа служат AP-AC-Pro. Мне очень нравится этот коммутатор, он очень мощный, к нему нет претензий, разве что только к управленческому ПО. Спасибо, di3, что поделился, реально ценю это.

NYRican79

Guest

09.04.2018 19:13:00

Я ценю все высказанные комментарии. Unfi Switch и Edge Switch — это одна и та же аппаратная платформа, так что, учитывая это, было бы легко добавить в Unfi Switch функции, которые есть у Edge Switch. Мне просто хотелось узнать, планирует ли Unfi расширить набор функций Unfi Switch, чтобы позволить сегментировать сети, даже если это будет статическая, а не динамическая сегментация. Единственная функция, которую я хотел бы видеть — возможность создавать разные сети на коммутаторе без необходимости использовать «роутер на палочке» или, в случае Unfi, «фаервол на палочке». Я считаю, что Unfi AP и бренд Unfi в целом просто потрясающие и очень мощные, но вот этой функции им не хватает. Я ищу именно эту возможность, и если удастся найти способ объединить управление или, по крайней мере, обеспечить совместимость между контроллерами Unfi и Edge, это было бы для меня идеальным решением.

di3

Guest

31.03.2018 02:48:00

@sirozha

Ты можешь говорить о всех технологиях, которые хочешь, о времени их появления и других вещах, даже о том, что это возможно сделать и что это может прийти. Но главный вопрос — кто будет покупать, зачем, и не увидят ли они другие возможности раньше? Я объясняю: то, что ты говоришь, правильно, но конкуренция и клиенты UBNT, на которых нацелена линейка продуктов Unifi, — это не те, кого ты описываешь, особенно если учитывать идею элитной поддержки. Это Cisco Meraki и им подобные, это другие IT-ориентированные среды с упрощённым управлением, а не крутые топовые или сложные функции. И если их сравнить, то ты увидишь, что они идут нога в ногу. Все те избыточности, про которые ты говоришь, либо отсутствуют как функции, либо появились недавно (отсюда, наверное, и разговор про L3, кстати).

Я не сотрудник UBNT, просто пытаюсь показать разницу и, возможно, куда стоит двигаться с продуктами edge или Unifi. Лично я бы предпочёл новую линейку продуктов, например, UNMS с удалённой консолью для реального времени, для настройки и управления версиями конфигураций (что, кстати, уже реализовано), но с дополнительной точкой доступа “Edge версия”. Потому что вижу, что большинство, кто хочет, чтобы Unifi делали больше — это те, кто начинают с линейки edge, а потом переключаются на беспроводную часть, Wi-Fi в основном. А так как для настройки всех этих устройств требуется контроллер Unifi, появляется «желание иметь контроллер Unifi и линейку продуктов, которые делают больше». В ответ UBNT в основном улучшает производительность железа и интерфейс, а не функционал (хотя IPS и IDS тоже хорошие).

В тот день, когда появится контроллер UNMS (а обсуждается именно он, а не L3, кстати!) с интегрированной точкой доступа, ты поймёшь разницу и почувствуешь, зачем нужен контроллер Unifi, если я могу самостоятельно централизованно настроить всю систему с помощью линейки edge и при этом не чувствовать, что чего-то не хватает в контроллере Unifi.

sirozha

Guest

31.03.2018 02:34:00

У каждого уважающего себя производителя есть L3-коммутаторы. Что такого сложного в реализации L3-коммутаторов в UniFi Controller? UBNT могли бы просто добавить ещё один тип «сети» в контроллер. Тогда можно было бы иметь два типа корпоративных сетей:

Тип 1. Корпоративная сеть с неограниченным L3-коммутированием (маршрутизация между VLAN происходит на L3-коммутаторе)

Тип 2. Корпоративная сеть с ограниченным L3-коммутированием (маршрутизация между VLAN на USG или стороннем роутере/фаерволе)

Если сеть настроена как Тип 1, то граница L3 — это SVI на L3-коммутаторе. Если сеть настроена как Тип 2, то граница L3 — это SVI на USG или стороннем роутере/фаерволе.

L3-коммутатор и USG обмениваются информацией через протокол маршрутизации (по выбору пользователя: OSPF, RIP или статические маршруты) для координации своих SVI. USG рекламирует в L3-коммутатор маршрут по умолчанию.

Если пользователь выбирает UniFi L3-коммутатор, но хочет использовать сторонний роутер/фаервол (например, pfSense), UniFi Controller настраивает L3-коммутатор и протокол маршрутизации, а сам сторонний роутер/фаервол пользователь должен настроить вручную. Для pfSense выбор протокола маршрутизации к UniFi L3-коммутатору — либо RIP, либо статические маршруты.

Если пользователь выбирает статические маршруты, UniFi Controller настраивает статический маршрут по умолчанию на роутер/фаервол для всех сетей Типа 2 и для всего трафика, направленного в интернет.

Естественно, L3-коммутаторы должны иметь возможность стэкинга для отказоустойчивости, чтобы L2-коммутаторы можно было подключать с двойными (multi-homed) uplink-каналами через LAG к стэку L3-коммутаторов. В стэке несколько коммутаторов работают как одно устройство L2/L3. Соответственно, у всего стэка одна CAM-таблица (таблица MAC-адресов) и одна таблица маршрутизации.

Кроме того, USG должен поддерживать активный/активный или активный/резервный режимы для отказоустойчивости роутера/фаервола и резервирования WAN/интернет-каналов.

Все перечисленные функции уже доступны у других производителей более 15 лет. Это самые базовые возможности. Сетевой компании просто невозможно ориентироваться на малый и средний бизнес без них.

sirozha Guest	#6 30.03.2018 13:27:00 Нет ответа. Отправлено с моего iPhone

di3 Guest	#7 30.03.2018 11:53:00 @sirozha => Я видел, что ты много участвуешь в обсуждении функций коммутаторов unifi L3. Получал ли ты какой-нибудь отзыв от UBNT по этому поводу? Потому что тема, если честно, сейчас почти мёртвая.

di3

Guest

30.03.2018 11:48:00

@sirozha

=> Ты упомянул e911, и при этом в том же посте говоришь про unifi: тут явно есть проблема, как и сказано, и основная проблема в том, что в unifi нет L3, потому что эта система изначально не предназначена ни для чего, кроме жилья, малого и среднего бизнеса. Если внимательно посмотреть на ACL, то видно, что их количество и/или синтаксис обычно ограничены. Среда unifi предлагает простую настройку с встроенной логикой: у тебя есть разные типы сетей (корпоративная, гостевая, только VLAN), которым разрешён определённый уровень доступа к другим VLAN, а для усиления этого централизуют маршрутизацию и файрвол на USG. Но тебе это не подходит, так как ты предпочитаешь иметь L3 и на коммутаторе, и на маршрутизаторе — справедливо, у тебя, кажется, критичные требования!

Однако инструмент, о котором мы говорим — unifi — изначально для этого не подходит. Возможно, что-то со временем изменится, но на данный момент L3-коммутаторы выведены из рассмотрения, вероятно, потому что они не совсем соответствуют философии продукта unifi и сложности управления логикой в мульти-L3-сетях, где и коммутатор, и роутер могут выполнять L3-обработку. Но, как уже сказано, твой пример верный, а вот ответ «используй unifi» может оказаться не самым правильным. Если линейка Edge тебе неудобна, возможно, стоит рассмотреть сторонние инструменты, которые позволят централизованно настраивать всё, или просто посмотреть на Cisco Software Stack — он позволяет централизованно управлять, версионировать и внедрять конфигурации для коммутаторов и маршрутизаторов и сам реализовывать часть логики.

Но не хочется снова и снова повторять одно и то же: на каждый вопрос есть ответ, но unifi — не всегда тот ответ :-)

sirozha

Guest

30.03.2018 11:12:00

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

Так что, если вопрос в том, зачем сегментировать хосты на несколько подсетей и потом организовывать между ними меж-VLAN маршрутизацию, то ответ — чтобы сократить размер широковещательных доменов. В одном широковещательном домене никогда не должно быть больше 254 хостов. Ещё одна причина использовать подсети /25, /26 и так далее — определить, в каких ERL находятся VoIP-телефоны, и назначить правильные ELIN для целей e911. Это лишь несколько очевидных примеров.

Такие подсети лучше маршрутизировать между VLAN с помощью L3-коммутатора, а не отправлять трафик вверх на роутер-on-a-stick для меж-VLAN маршрутизации.

Отправлено с моего iPhone

di3

Guest

#10

30.03.2018 04:01:00

@NYRican79

=> Мы можем часами обсуждать L2 или L3 маршрутизацию (всё сводится к некоторому сопоставлению, а L2 работает только по назначению, тогда как L3 проверяет и источник, и назначение, и в итоге NAT, если нужно ;-)

) В любом случае, я понимаю твоё отношение к продуктам EdgeMax и Unifi. По моему опыту, Unifi — это простая и удобная установка с множеством автоматических процессов, вроде статистики и настройки элементов (например, VLAN на всех устройствах), но, как ты правильно отметил, линейке Edge (edgerouter, edgeswitch) не хватает «чего-то», особенно в ситуации, которая знакома многим: сеть WAN/LAN построена на Edge, а WLAN — на Unifi. В итоге у тебя получается два инструмента для одной сети! И, как ты сказал, Unifi не может справиться со всем!

Я бы сказал так: UBNT не слишком заинтересованы делать мощные инструменты для линейки Edge, и тем более — Edge-based точку доступа, поэтому между ними явно есть пробел, что вызывает непонимание у многих пользователей (я лично чаще выбираю Unifi, чтобы получить простую настройку с нормальной «масштабируемостью» и возможностью адаптироваться под разные условия), но для остальных, как ты, я понимаю эту боль!

Возможно, появятся сторонние инструменты или универсальный API для продуктов Edge, но твоя точка доступа Unifi всё равно останется вне их зоны покрытия… Сложный выбор и ситуация! Посмотри, может идея L3-коммутатора в линейке Unifi вернётся! Надеюсь на это и для тебя, и для себя — чтобы можно было охватывать ещё больше случаев и задач с помощью Unifi! Удачи.

di3

Guest

#11

30.03.2018 03:36:00

@NYRican79

=> Я начал работать с мультикастом и широковещанием, так как рано или поздно получил похожие задачи. Если посмотреть на конфигурацию свича, то, как минимум, если широковещательный шторм — это проблема, её можно легко контролировать через настройки свича. При этом вы увидите улучшение производительности самого свича (меньше загрузка CPU, а значит ниже энергопотребление).

Что я сделал: использую одну VLAN, так что по умолчанию всё работает на уровне коммутации, кроме защищённого оборудования (IoT, CCTV, DMZ). Сервисы, такие как VOIP, находятся в той же сети, что и IP-сеть. Поля DSCP в телефоне позволяют приоритизировать трафик прямо на свиче, а умная очередь USG снижает задержки.

Настройки портов свича контролируют широковещательный и мультикаст трафик: порты VOIP не разрешают мультикаст и сводят широковещание к минимуму (но оно всё равно нужно хотя бы для DHCP!).

Это моё мнение, но я понимаю, зачем L3 может иметь смысл — чтобы упростить настройку и приблизиться к производительности коммутации. Хотя L3 всё равно добавляет задержку, даже в свиче, потому что всё равно нужен L3 lookup (по порту)!

Удачи! Похоже, что L3-свичи появятся не скоро, они ещё не вышли на альфа-стадию.

NYRican79

Guest

#12

30.03.2018 03:20:00

Я хочу сегментировать свою сеть, поэтому наличие L3-контроллера критически важно. L3-коммутатор позволяет избежать узких мест, потому что маршрутизация происходит внутри конструкции коммутатора. Если бы мне пришлось маршрутизировать через роутер по гигабитной линии, я бы ограничивал производительность. А если делать это внутри коммутатора, я использую пропускную способность самой конструкции, да и маршрутизация на коммутаторе происходит на ASIC, что гораздо быстрее.

Когда все устройства находятся в одной широковещательной области, возможны широковещательные штормы, а ещё трафик, который мне может не понадобиться на другой сети. Например, я могу не хотеть Bonjour в одной сети, но использовать его в другой. Или хочу разместить сервер в отдельном сегменте, где больше контроль, чем в пользовательском или голосовом сегменте. Разделение сетей упрощает поиск проблем и управление трафиком.

Безопасность, разумеется, тоже плюс. Можно настроить базовые ACL для контроля трафика, но, по мне, это зависит от конкретного сценария использования.

Понимаю, что для большинства людей L3 может быть не нужен, и это нормально. Я же смотрю глубже и хочу использовать обе продуктовые линии, управлять ими из одного интерфейса. Если предстоит оставить Access Point в UniFi, это меня устраивает, я просто хочу иметь возможность видеть трафик через линейку EdgeMax, чтобы управлять ресурсами сети и быть проактивным и оперативным.

Если получится сделать UNMS главным менеджером (MOM — mother of managers), а контроллеры UniFi использовать как менеджеры конфигурации для продуктов UniFi, меня это полностью устроит.

di3

Guest

#13

29.03.2018 23:17:00

@NYRican79

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

Если безопасность не нужна, тогда достаточно просто коммутации, так зачем в таком случае не использовать один IP-диапазон и VLAN? Мне этот вопрос задавали несколько недель назад по поводу некоторых элементов SAN, к которым можно получить доступ только с внутренней LAN (VLAN 1), но не с VLAN 2 для гостей. Почему не делать L3 на свитче, если создать VLAN 3? Просто потому что в 99% случаев, проще всего просто поместить SAN в VLAN 1! Так это останется коммутацией и будет работать на полной пропускной способности!

Один из крайних случаев: если двум VLAN нужно получить доступ к одному и тому же SAN, но при этом VLAN не должны общаться друг с другом. Сейчас можно легко назначить SAN два IP-адреса — по одному на каждый VLAN, даже сделать trunk нескольких интерфейсов, если SAN их поддерживает, и в итоге получить доступ к SAN из обеих VLAN.

Лично я считаю, что L3-маршрутизация полезна в снижении нагрузки на роутер, пока не понимаешь, насколько бедные ACL бывают, и тогда понимаешь, что L3 на роутере и L2 на свитче могут отлично дополнять друг друга. А L3 на свитче часто переоценивают в 90% IT-сценариев (прошу воспринимать это как правило для большинства случаев, а не для всех).

NYRican79

Guest

#14

29.03.2018 21:50:00

Думаю, одна из самых больших проблем такого раздельного подхода — это сама эта сегрегация. Понимаю, если у тебя есть Max Edge AP, то такой вариант логичен. Но я вижу, что если тебе нужен коммутатор уровня 3 и Wi-Fi, то приходится использовать разных управляющих. Было бы здорово как-то передавать информацию из Unifi (клиенты, производительность, радиочастотный спектр и т.д.) в UNMS, чтобы с одного контроллера можно было наблюдать всю среду. Коммутатор Unifi сейчас не умеет маршрутизировать, поэтому возможности ограничены. У меня есть задача — иметь 2 SSID на разных сетях и уметь маршрутизировать это на коммутаторе без схемы “роутер на палочке”. Мне очень нравится софт, просто хотелось бы, чтобы он лучше интегрировался с Unifi.

jmkuchta Guest	#15 21.12.2017 02:38:00 @di3 Спасибо, что вообще ответил на вопрос.

tickett

Guest

#16

10.12.2017 16:21:00

Лично я бы очень хотел увидеть их в одном месте. С трудом понимаю смысл держать их раздельно.

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

di3

Guest

#17

09.06.2017 06:48:00

@sirozha

=> Между продуктовыми линейками Broadband (EdgeMax, AirMax, EdgeSwitch) и Unifi существует огромная разница в концепции.

Линейка Unifi, особенно через контроллер, это:
- полностью автоматизированная настройка: контроллер настраивает каждый элемент индивидуально на основе вашей конфигурации (то есть вы делаете дизайн сети один раз, а конфигурации применяются сами без вашего вмешательства)
- интеграция в контроллер для статистики, производительности и обработки данных
- ограничение в дизайне зависит от возможностей контроллера (в общем, контроллер не может сделать всё, а только отдельные части, но с течением времени добавляются новые функции)

Линейка Broadband:
- никакой автоматизации, каждый элемент нужно настраивать вручную (через HTTPS или CLI)
- UNMS позволяет собирать, создавать резервные копии и восстанавливать конфигурации
- централизованно отображает статус и производительность устройств
- ограничения в дизайне зависят от прошивок на устройствах: используя HTTPS и CLI, вы можете сделать гораздо больше

Итог: если вы точно знаете, что хотите сделать — выбирайте UNMS/Broadband, но будьте готовы делать всё вручную.
Если нужно быстро развернуть простое и интегрированное решение с проверенным дизайном сети — выбирайте линейку Unifi.

На данный момент нет планов их объединять, и это логично, ведь они не нацелены на одну и ту же аудиторию/пользователей/администраторов. И пусть так и останется: мне нравится простота Unifi, а администраторы Broadband любят гибкость и расширенные возможности железа. UNMS хоть немного помогает лучше управлять их конфигурациями ;-)

Moscato Guest	#18 09.06.2017 01:42:00 Ты бы знал гораздо лучше, чем я.

eejimm

Guest

#19

09.06.2017 00:24:00

Могу ответить на этот вопрос — нет. Планы использовать UNMS вместо контроллера UniFi нет. Они выполняют разные задачи для разных продуктовых линеек. В какой-то момент (четвёртый квартал этого года, согласно опубликованному графику) UNMS сможет мониторить контроллеры UniFi как конечные точки в UNMS. Это будет нужно, чтобы убедиться, что они на месте, и получить базовую информацию, но не для полного управления, как это уже делает UniFi. Контроллер UniFi останется основным способом настройки и управления продуктами UniFi. Джим

Moscato Guest	#20 09.06.2017 00:14:00 Думаю, unms — это, вероятно, предлагаемая замена контроллера UniFi, чтобы они могли расширить функционал.

Читают тему (гостей: 1)