С радостью, и я рад, что вам удалось разобраться! Я просто собрал воедино знания других Надеюсь, в будущем Unifi сможет либо самостоятельно с этим справляться, либо давать рекомендации и заблаговременно предупреждать пользователей, что это может стать проблемой, ведь вся необходимая информация должна храниться в контроллере Unifi, а управление этим основано на довольно простых правилах.

Для меня это было просто — выключить Wi-Fi на моем Mac. (При подключении к Ethernet)

Вы не можете контролировать STP на «коммутаторе» UDM Pro — потому что это на самом деле не коммутатор. Просто используйте один порт для подключения к остальной части вашей сети, и лучше не обращайте внимания на остальные порты. Я действительно не понимаю ни одного из дизайнерских решений для этого «коммутатора», встроенного в UDM Pro.@DWBAdmin тоже. Как только я отключил всё с «коммутатора» UDM Pro, оставив только один даунлинк к моему основному коммутатору, все странные проблемы исчезли.

Благодарю за предоставленную информацию, но у меня возник ещё один вопрос: на UDM Pro будет ли встроенный коммутатор основным (4096) и как настроить его приоритет? В контроллере нет такой настройки в разделе «Services», как у моих связанных коммутаторов.

Спасибо, это решило мою проблему при добавлении старых TP_link к сети.

Хороший вопрос. У меня тоже возникают проблемы с тем, что случайные SFP-порты блокируются. У меня есть UDM Pro и 11 коммутаторов, соединённых в кольцевую топологию. На коммутаторе 11 установлен приоритет 4096, так как к нему подключён роутер. Остальные коммутаторы имеют приоритеты, кратные 4096, начиная с коммутатора 1. Только что перезагрузил коммутатор 2, и у коммутатора 5 заблокировался SFP-порт. Странно. @mjudecollins, у тебя удалось решить проблему? С уважением.

Привет! Хотел добавить к этой теме, потому что у меня была такая же проблема, и ни одно из предложенных решений не сработало. Я вручную выставил приоритеты на своих свитчах, отключил точку доступа (чтобы у неё не было клиентов), отключил свитч, к которому она была подключена (чтобы буквально ничего не могло вызвать петлю на этом порту), но STP всё равно отключал порт, к которому была подключена эта точка доступа. Статус точки доступа оставался «Connected (Wireless, Disabled)».

Проблема была в том, что, поскольку точка доступа начала работать как mesh-точка, именно этот беспроводной маршрут вызывал петлю (я думал, система была бы умной и по умолчанию убавила бы приоритет у беспроводного маршрута, но, видимо, нет). Мне пришлось зайти в настройки этой точки доступа, перейти в раздел Wireless Uplinks и отключить опцию «Allow meshing to another access point», чтобы STP наконец разблокировал порт. (Кажется, я ещё перезагружал точку доступа после этого, чтобы обновление вступило в силу, но точно не помню.)

Бьюсь об заклад, кто-то просто воткнул другой конец патчкорда в любой свободный порт на свитче. Не то чтобы у меня были пользователи, которые так делают, «чтобы было аккуратно и надежно». Если это удаленный объект, к которому имеют доступ разные люди, такие штуки очень помогают обеспечить правильное управление изменениями: http://www.padjack.com/padjack-versions/padjack-sve-rj45-lock/ Есть и другие производители с похожими решениями. Это не тот, о котором я думал, но первый, что вылез в поиске 😀

Да, в интерфейсе отображается как заблокированный. Странно, что я, похоже, не вижу ни одного клиента, подключённого к этому порту. В следующий раз, когда буду там, проверю физически. Всё это вижу через cloudkey. Порт показывает зелёный и статус заблокирован.