Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Как сохранить приоритет STP-порта/пути (не коммутатора)?, wifiman
 
У меня есть 2 коммутатора USW Enterprise 8 PoE L3 в моей сети. Один находится в удалённом офисе, поэтому он подключён к другому по двум отдельным маршрутам. Один — 10 Гбит/с (SFP+ каналы) основной, а другой — 2,5 Гбит/с (RJ-45) в качестве вторичного. Использовать LAG нельзя, так как скорости портов разные, и нельзя использовать оба SFP+ канала для этого, так как один используется для подключения к основному коммутатору USW Aggr. Я пытался настроить LAG просто ради смеха с разными скоростями, но это заканчивается хаосом. Так что вернулись к моему первоначальному плану — 1 x 10 Гбит/с основной и 1 x 2,5 Гбит/с резервный. Отлично… Проблема в том, что по какой-то причине, известной только Ubiquiti, они установили «стоимость» порта RJ-45 НИЖЕ, чем у порта SFP+. Таким образом, когда подключены оба канала, коммутатор использует 2,5 Гбит/с в качестве основного (я предполагаю, что стоимость пути превосходит стоимость порта, иначе бы всё работало как ожидалось…). В GUI сейчас нет способа изменить это. Я остаюсь с одним портом, "отключённым", и, в случае проблемы, вынужден вручную заходить и включать его (это предполагает, что проблема на контроллере той же линии связи, конечно!). Кажется абсолютно безумным. Большая пропускная способность 10 Гбит/с — это огромный плюс для этого соединения (в течение дня в пиковые моменты нагрузка на несколько устройств действительно возрастает). Так что — копаемся в CLI, и, довольно приятно, похоже на Cisco… Нашёл нужную область довольно быстро…Ent-8PoE#sh spanning-tree TenGigabitEthernet 1 Port te1 enabledState: forwarding                                Role: designatedPort id: 128.9                                 Port cost: 2000Type: P2P   (configured:Auto ) RSTP    Port Fast: No (configured:Auto)Designated bridge Priority : 8192          Address: xxxxDesignated port id: 128.9                      Designated path cost: 2000Guard root: Disabled                           BPDU guard: DisabledGuard tcn: DisabledNumber of transitions to forwarding state: 1BPDU: sent xxxx, received xxxx-------------Ent-8PoE#sh spanning-tree TwoPointFiveGigabitEthernet 8Port tw8 disabledState: disabled                                Role: disabledPort id: 128.8                                 Port cost: 2000000Type: N/A (configured:Auto ) RSTP       Port Fast: No (configured:Auto)Designated bridge Priority : 8192          Address: xxxxDesignated port id: 128.8                      Designated path cost: 0Guard root: Disabled                           BPDU guard: DisabledGuard tcn: DisabledNumber of transitions to forwarding state: 0BPDU: sent xxxx, received xxxI могу легко снизить стоимость пути/порта на SFP+ - SFP+ канале ниже стоимости RJ-45 - SFP+ канала. Забавно, но…настоящий вопрос здесь….Есть ли кто-нибудь, кто знает, как можно перманентно сохранить "стоимость порта/пути" в CLI на этих устройствах?Любые крупицы мудрости приветствуются.
 
Они должны быть для Контроллера, то есть могут охватывать интерфейсы, связанные с шлюзом, коммутаторами, точками доступа и т.д. Но реализация довольно устаревшая, так что, конечно, нужно быть осторожным (хотя бы тестировать в не-продакшене), прежде чем на неё полагаться.
 
Разве это только для UDM/UDM Pro/Gateways? Ему нужно сохранить изменения на коммутаторах USW Enterprise.
 
@WickedWeasel ты в итоге разобрался с этим? Саппорт так и не ответил тебе по поводу стоимости пути?
 
Похоже, это ошибка с низкой степенью серьезности (не приводит к падению, но функциональность сохранена) и, возможно, с низким приоритетом, в зависимости от количества пользователей, которые ее сообщают. Хотя сложно сказать наверняка, возможно, это реализовано в какой-то тестовой ветке. Удачи в разгадке!

Есть некоторые реализации сохранения состояния в инструментах Git. Я использовал это несколько лет назад для регулярного перезапуска сетевого процесса (в эпоху утечек памяти), и, кажется, они обновлены, используйте на свой страх и риск: unifios-utilities/persist-changes at main · unifi-utilities/unifios-utilities · GitHub. В противном случае, они будут сохраняться до перезагрузки или перезапуска сетевого процесса по какой-то причине — не очень хорошо для использования в продакшене.
 
Спасибо за ответ. Да, пробовал службу поддержки – они подтвердили, что скорость порта – это обязательное условие, и поэтому нельзя объединить 10Gb и 2.5Gb. Вроде бы и понятно, как это работает, но я все же подумал, вдруг они что-то там хитроумно делают в фоне, потому что на первый взгляд GUI позволяет это сделать… Служба поддержки только что еще раз подтвердила мне, что "виновником" является "стоимость пути", и "они продолжают расследование". Не уверен, что из этого вытащить… Это ошибка, и они собираются исправить ее, или просто признают, что это нужно изменить? Кажется странным, что RJ45 порт имеет более низкую стоимость, чем SFP+ порт, но что поделать… Попробую внести изменения в CLI, но не уверен, как долго они сохранятся, прежде чем будут перезаписаны. Попробую сначала. Предполагая, что я не вношу никаких других сетевых изменений, влияющих на эти коммутаторы, надеюсь, это продержится, пока мне не придется вносить изменения или обновлять прошивку… Еще раз спасибо.
 
Ну, конфигурация довольно странная, но похоже, что должна работать, учитывая последовательные порты. Я никогда не пытался объединить Ethernet и SFP(+) порт, даже не видел, чтобы об этом спрашивали (хотя уверен, где-то это встречалось). В FAQ по агрегации не указано, что скорость порта — обязательное условие. Ты пробовал обратиться в поддержку? Если нет, то, кроме этого, два USW Agg и модули MG (около 600 штук, не так уж и много, но и не дёшево) — вероятно, лучший способ заставить это работать с Unifi.
 
Большое спасибо за ответы. Извините, это скорее «работа в процессе», я обновлял пост по ходу дела...В ответ на вопрос: «Когда вы говорите о раздельной маршрутизации, вы имеете в виду физически разные L2, а не L3, верно?» — Верно, разная кабелька. "Не знаю, к чему вы имеете в виду, когда упоминаете порты LAG, заканчивающиеся бардаком?" Так что LAG / LACP / PAgP / EtherChannel / 802.3ad или как там это называется нынче, работает на основе того, что все ссылки в «связке» должны быть одинаковой скорости и конфигурации. Я попробовал настроить связку с 10Гб ссылкой и 2.5Гб ссылкой больше из любопытства. Интерфейс это разрешил (Cisco бы точно не позволила), но в итоге было куча потерянных пакетов, так что, наверное, то же самое и с Ubiquiti, даже несмотря на то, что кажется, что она это допускает...Вы правы — можно было бы добавить пару USW Aggr, 10Гб ссылку с каждого Ent-8 и LAG из двух 10Гб соединений между Aggr-коммутаторами, и это бы работало очень хорошо, но сейчас бюджета на дополнительное оборудование нет, и, по сути, того, что у нас есть, должно хватить для 10Гб основной линии и 2.5Гб резервной.
 
Не самое элегантное (и экономически эффективное) решение, но можно попробовать использовать пару USW-Aggregation коммутаторов и пару модулей с поддержкой мультигигабита (для соединения на 2.5 Гбит/с). По крайней мере, я почти уверен, что это сработает, учитывая спецификации и то, как хорошо работает LAG на паре портов GbE...Не уверен, это ли вы имеете в виду, когда говорите о "беспорядке" в портах LAG?
 
Unifi реально не поддерживает настройку стоимости порта и что-то подобное в CLI. Когда ты говоришь о раздельной маршрутизации, ты имеешь в виду физически разные L2, а не L3, правильно? Стоимость портов определяется номером. Для портов одинаковой скорости, чем меньше номер, тем выше приоритет. Проблема часто в том, что SFP+ временно договаривается или сообщает о 1GbE, и в момент расчета приоритетов это ставит его ниже порта 2.5GbE. Лично я считаю, что отказы STP не стоят того крошечного преимущества, которое можно получить от резервного соединения.
Страницы: 1
Читают тему (гостей: 1)