Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Задержка функций ECS Aggregation Switch?, UniFi Network
 
Кто-нибудь знает, когда выйдет VRRP? Мы купили 2 коммутатора ECS в начале года в надежде, что летом эта функция появится, так как изначально было сказано, что она будет в следующем релизе. Однако мы заметили, что теперь на странице (https://uk.store.ui.com/uk/en/category/switching-aggregation/products/ecs-aggregation) говорится иначе. На скриншоте от января видно, что VRRP должна была появиться в следующем релизе, но мы прошли через версии 9.1, теперь на 9.3, а её до сих пор нет.
 
На этих коммутаторах просто "cli" не существует. "Новый" вариант cli называется "uicli" и предоставляет тот же полнофункциональный инструмент конфигурации cli, как на предыдущих моделях.
 
ssh inclienconf?[subcommand xyz ?]
 
Как видишь, в данный момент никто не может поделиться какими-то конкретными деталями. К тому же UI и их обещание "скоро будет доступно" оставляет желать лучшего, как бы мы это ни крутили. Лично для меня это была проблема с выпуском L3-функции в целом. Эти коммутаторы выкатывали годами, а мы ВСЕ ЕЩЕ получаем функции, которые у большинства вендоров работают с первого дня. Я не говорю, что UI — это самое плохое, но если тебе нужна какая-то функция для развертывания продукта, вот мои советы:

Убедись, что функция официально поддерживается.
Подготовь ПОЛНЫЙ план тестирования для проверки твоей новой покупки.
Как только получишь оборудование, не теряй время и выполняй свой скрипт.
Держи в резерве альтернативного вендора на случай проблем.

Кстати, мне тоже нужен VRRP для одного из моих проектов, и пока я им говорю ждать.
 
К слову, это относится практически к любому поставщику. Сейчас много вендоров добавляют safe-harbor statements/disclaimers каждый раз, когда говорят о "будущих" функциях, указывая, что гарантий нет. В основном это нужно для защиты от финансовой ответственности, особенно для публичных компаний, но смысл применим в целом: планы на будущее не гарантированы. Полностью согласен. Я уже не раз писал это в разных постах: принимай решение о покупке на основе функций и возможностей, которые уже доступны, а не на предположения о том, что будет в будущем. Тогда любые новые функции, которые всё-таки добавят, будут приятным бонусом.
 
@mightymike87, как давний пользователь UI и альфа-тестер (и не только, если что ;-), я вам скажу прямо: если вы покупаете оборудование UI в ожидании функций, которых ещё нет, то вы идёте прямо в ловушку. Я обожаю UI всей душой — вся наша крупная интернет-компания построена на оборудовании UI — но если вам срочно нужна какая-то функция, а её ещё не выпустили, то не ставьте на это всё своё состояние. UI неоднократно приходилось менять свои планы, когда аппаратные или программные проблемы оказывались серьёзнее, чем они предполагали. И вы можете попасть в неприятную ситуацию, если не будете осторожны.

Вот один пример — LTU. Когда разрабатывали первые LTU-радиомодули, их всегда видели как следующее поколение PtMP-платформы UI, начиная с AF5xHD, который использовался бы и как клиентское оборудование, и как точка доступа. Но во время разработки выяснилось, что сложность PtMP (особенно когда клиенты находятся на радикально разных расстояниях) требует больше мощности, чем мог предоставить 5xHD. Поэтому UI пришлось разработать LTU-AP для этого. Вина никого, но потребовалось много реальных полевых тестов, чтобы это понять, а это занимает время. Те, кто использовал 5xHD как точку доступа в многоточечной сети (мы тоже, правда только с несколькими абонентами), вынуждены были всё переделывать, когда вышел LTU-AP. Поскольку мы были тестерами, мы ожидали таких вещей. Но множество людей за эти годы попались на удочку, делая ставку на функцию, которая так и не реализовалась.

Я не говорю, что VRRP и всё остальное никогда не появится, но если вам это критически нужно прямо сейчас, то купите то оборудование, которое это уже имеет... Jim
 
Похоже, что в CLI есть команда 'config vrrp' и несколько подкоманд, так что это немного вселяет надежду на то, что официальная функциональность скоро появится.
 
На более новых коммутаторах требуется ввести команду "cli", чтобы попасть в реальный интерфейс CLI коммутатора. Без этого вы остаётесь на уровне управления UniFi, а не на уровне реального управления коммутатором. Попробуйте ввести "cli", а затем снова используйте ?/help.
 
Надеюсь, ты прав и это произойдёт достаточно скоро. Я бы предпочёл, чтобы это работало на VLAN интерфейсах, а не на файрволе (Palo Altos), так как безопасность была бы лучше, но пропускная способность не будет, а у нас есть пользователи, которые очень требовательны к полосе пропускания.
 
Отличная идея, но, к сожалению, здесь ничего нет. Доступны только следующие варианты:

info — вывести информацию об устройстве
set-default — восстановить заводские настройки
set-inform <inform_url>
upgrade <firmware_url>
fwupdate --url <firmware_url|firmware_name> [--dl-only] [--md5sum <sum_of_fw>] [--keep-firmware] [--keep-running] [--reboot-sys] — команда обновления микропрограммы
reboot — перезагрузить устройство
 
Я понимаю, но меня беспокоит, что функция должна была выйти в следующем релизе, 9 месяцев назад, а теперь она перейдена в статус "планируется" без видимого конца. Это самые дорогие коммутаторы, которые продаёт Ubiquiti, и если качество выполнения обещаний будет таким же, я предпочту не связываться с чем-либо ещё, что они обещают. Вот ответ от поддержки, который убедил меня, что эта функция никогда не выйдет:

На данный момент текущая реализация MC-LAG на коммутаторах агрегации ECS в основном предназначена для избыточности канального уровня и агрегации каналов. Использование интерфейсов VLAN таким образом, чтобы они функционировали как совместный шлюз (например, похожий на VRRP) между обоими узлами MC-LAG, не входит в текущую поддерживаемую конструкцию. Некоторые связанные функции рассматриваются для будущих обновлений, но у нас пока нет публичного графика или финализированных деталей реализации. Пока что, если функциональность уровня 3 требуется в вашей топологии, мы обычно рекомендуем завершать функции маршрутизации на централизованном или вышестоящем шлюзе, находящемся вне пары MC-LAG, чтобы обеспечить оптимальное поведение.
Страницы: 1
Читают тему (гостей: 1)