Привет, @JNelson159, какой лишний линк ты использовал, чтобы вызвать лавину? Также, пожалуйста, пришли новый файл поддержки (так как ты заменил core switch 1) и предоставь информацию об устройствах двух своих USW-Aggregations.

@UI-Team @UI-Glenn, есть у вас какие-нибудь новости?

@UI-Glenn Файлы загружены. Дайте знать, если понадобится что-то ещё.

Тоже самое.

Я запустил свою конфигурацию и теперь у меня есть теория, что происходило. Во-первых, мой стек состоит из 2 x US-16-XG, 1 x US-48-G1 и 1 x US-48-500W-коммутаторов. Вот что я сделал. Я отключил все резервные подключения, выключил STP на коммутаторе и в профилях портов. Затем обновил прошивку на своих коммутаторах до версии 5.64.8.13083; обновление прошло гладко. Потом я заново включил RSTP на коммутаторах и в профилях портов, но НЕ подключал резервные соединения обратно. Оставил стек коммутаторов в покое на пару дней, чтобы посмотреть, что будет. У меня есть syslog-сервер, который собирал логи, и я следил, какие сообщения появляются. Заметил, что каждые 6-12 часов происходит “инцидент”, когда один или несколько коммутаторов вылетают и потом заново присоединяются. Иногда один, иногда несколько. Сообщения выглядели так:  

----------  
Nov 2 08:01:53 cedar-usw-core16-1.cedar-republic.com b4fbe41cf977,US-16-XG-5.64.8+13083: mcad: mcad[3347]: ace_reporter_trsp_curl.check_multi_info(): inform failed with curl code 7
Nov 2 08:01:53 cedar-usw-core16-1.cedar-republic.com b4fbe41cf977,US-16-XG-5.64.8+13083: mcad: mcad[3347]: ace_reporter.reporter_fail(): Unreachable (http://unifi.cedar-republic.com:8080/inform)  
Nov 2 08:01:53 cedar-usw-core16-1.cedar-republic.com b4fbe41cf977,US-16-XG-5.64.8+13083: mcad: mcad[3347]: ace_reporter.reporter_fail(): inform failed #1 (last inform: 55 seconds ago), rc=3
Nov 2 08:02:21 cedar-usw-core16-1.cedar-republic.com b4fbe41cf977,US-16-XG-5.64.8+13083: mcad: mcad[3347]: ace_reporter_trsp_curl.check_multi_info(): inform failed with curl code 7
Nov 2 08:02:21 cedar-usw-core16-1.cedar-republic.com b4fbe41cf977,US-16-XG-5.64.8+13083: mcad: mcad[3347]: ace_reporter.reporter_fail(): Unreachable (http://unifi.cedar-republic.com:8080/inform)  
Nov 2 08:02:21 cedar-usw-core16-1.cedar-republic.com b4fbe41cf977,US-16-XG-5.64.8+13083: mcad: mcad[3347]: ace_reporter.reporter_fail(): inform failed #3 (last inform: 83 seconds ago), rc=3
Nov 2 08:02:21 cedar-usw-core16-1.cedar-republic.com b4fbe41cf977,US-16-XG-5.64.8+13083: mcad: mcad[3347]: ace_reporter.reporter_fail(): [STATE] entering SELFRUN!!!!
----------  

...и иногда...  

---------  
Nov 3 13:57:16 cedar-usw-core48-2.cedar-republic.com syslog: mcad[1215]: ace_reporter.reporter_fail(): Unable to resolve (http://unifi.cedar-republic.com:8080/inform)  
Nov 3 13:57:16 cedar-usw-core48-2.cedar-republic.com syslog: mcad[1215]: ace_reporter.reporter_fail(): initial contact failed #35, url=http://unifi.cedar-republic.com:8080/inform, rc=1
---------  

DNS-серверы доступны через фаервол, который подключён к верхнему 16-XG-коммутатору; я подозреваю, что когда он глючил, другим коммутаторам было трудно добраться до DNS. На всякий случай, если проблема была именно в Windows DNS-серверах, я изменил настройку pfSense так, чтобы он напрямую резолвил адрес контроллера unifi без передачи запросов в Windows AD на другом подсети; но, по моим наблюдениям, это не повлияло.  

Пробовал вернуть одно из резервных соединений — заметил, что инциденты стали чаще. Сразу же отключил их обратно. Это навело меня на мысль, что проблема не столько в STP или RSTP, сколько в периодическом соединении inform. Когда включен STP и коммутаторы глючат, подозреваю, что они начинают пропускать трафик, который надо блокировать — и это вызывает шторм, который усугубляет зависания ещё больше. В итоге оба фактора вместе вгоняют систему в полный отказ.  

Решил попробовать обновить контроллер. Раньше у меня была версия 6.0.43, обновил до 6.4.54. После обновления заметил, что больше не стало никаких инцидентов или проблем с периодическим inform. Подождал день, потом включил одно из резервных соединений — проблем не было, порты блокировались как положено. Отключил одно из основных соединений — резервное стало активным. Вернул основное — снова заблокировалось. Прошёл пока всего день, но пока всё работает стабильно. Похоже, что именно обновление контроллера решило эту проблему. Посмотрим через неделю, останется ли так, но пока коммутаторы в syslog ведут себя очень спокойно.

@UI-Glenn @UI-Team Когда это наконец исправят? Я сообщал об этой же проблеме для версии 5.43.18.12487 больше года назад. Каждая новая прошивка, которую я смотрю начиная с 4.3.22, продолжает иметь точно такую же неисправность. Единственное, что мне посоветовали, — отключить STP в профиле и включать только RSTP как сервис на коммутаторе, и это вообще не логично, особенно учитывая, что ваше ПО явно рекомендует не отключать его в профиле. Какая комбинация настроек вообще заставит это работать? Если у вас возникают трудности с воспроизведением проблемы в лаборатории, то скорее всего дело связано с процессом обновления. Какая-то настройка из версии 4.3.22 или раньше не сбрасывается и не меняется при обновлении, что и ломает всё. Может, у коммутаторов с новой прошивкой этой проблемы нет — не знаю. Но было бы здорово, если бы наконец обратили внимание на проблему, о которой уже столько раз сообщили и в таком количестве прошивок.