XG был заменён, и теперь установлен второй 8-портовый агрегирующий коммутатор, при этом резервные каналы переключены с 1G на 10G для поддержания производительности. Всё теперь идеально: ни одного критического состояния порта не обнаруживается при нормальной работе, а при сбое любого коммутатора результат – «Ну и что», хотя сигнализирует куча тревог мониторинга. Меняем и продолжаем работать как обычно.

Мне не нравится, что этот XG начал сам по себе так капризничать, некоторые теоретики заговоров, возможно, уже называют это встроенным устареванием, но теперь я уверен, что кластер серверов будет работать, как и ожидалось, независимо от того, что случится с сетью. Кидай деньги на «проблему» — и она решится.

Чтобы не уходить в сторону, единственное, что меня теперь раздражает при настройке резервных сетевых каналов, — это то, что когда RSTP блокирует избыточные порты, это отображается как «критическое» состояние... То есть ситуация, когда с «странного» превращается в «обычное», вдруг становится «критичной». Это специально сделанная избыточность, зачем же тогда её считать «критичной»? Я так и задумал, так что просто тишина — перестаньте меня донимать случайными тревогами и интерфейсом, переполненным красным цветом = плохо. Дайте простой способ обозначать: «Этот порт выполняет роль резервного», и пусть мониторинг и логи ведут себя соответствующим образом. Например, галочка «не сообщать» или, если сообщать, то на уровне INFO. Вот для этого и родился протокол Rapid Spanning Tree — быстро менять предпочтительные пути трафика при изменениях топологии, то есть при сбоях. Кольцевые топологии существуют благодаря RSTP, и теперь у меня есть 10G-кольцо после переделки, вызванной тем, что проблемный XG вышел из строя и был заменён не на один, а на два коммутатора.

Никакие изменения приоритетов RSTP на коммутаторах в моей сети этого не исправили, но теоретически я могу что-то упустить. Хотя, скорее всего, нет, ведь у каждого коммутатора свой приоритет: 0 — ядро, подключённое к Интернету; 4096 — второе ядро; 8192 — третье ядро, вот и кольцо. Все конечные узлы настроены на возрастающие и разные приоритеты.

Спустя какое-то время ничего не изменилось: все ссылки на серверах показывали красный критический треугольник. Я потерял терпение и последовал примеру @ChrisD., решив, что XG мне ничего не должен финансово, ведь ему больше 6 лет, а красные треугольники и повреждённые отчёты DAC вызывают у меня дискомфорт в любом месте, кроме домашней лаборатории.

Я тоже заменил его на 8-портовый агрегирующий свитч, упростив пару портов back-end/front-end до одного 10-гигабитного канала на каждый узел кластера, что уменьшило количество необходимых портов (при этом сохранился резервный канал на 1 Гбит/с). Тестирование показало, что объединение front-end и back-end (в нормальном режиме работы) по-прежнему хорошо справляется со своей задачей. Если 10-гигабитный свитч выйдет из строя, тогда будет тяжеловато, потому что останется всего один общий канал 1 Гбит/с на узел. Возможно, мне придётся поставить второй агрегирующий свитч для резервного 10-гигабитного канала и отказаться от 1 Гбит/с, но это пока можно подождать.

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

Я заменил свой US-16-XG на 8-портовый Aggregation, и проблема исчезла. Тот же DAC, те же клиенты и всё такое.

+1

Я тоже, 32-портовый агрегат.

У меня такая проблема на моём US 16 XG.

Та же проблема у меня. Как может быть предупреждение на отключённом порту? У меня 48 POE pro max, который был подключён к порту 17 моего Aggregation pro (на фото). После долгих раздумий решил: «А что если сменить порт?» Конечно, переподключил к порту 15, и уже два дня предупреждения нет. Тогда я отключил этот порт и выключил POE, а предупреждение всё равно есть? Странно.

Да, у меня так же... Проблем нет, всё работает, но в интерфейсе всё равно появляется это сообщение

Похоже, у вас появляется предупреждение «Loss of Tx signal detected» на порту US-16-XG SFP+. Вот несколько шагов, которые можно попробовать, чтобы решить эту проблему:

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

Осмотрите трансиверы: убедитесь, что SFP+ трансиверы правильно вставлены в порты и работают нормально. Попробуйте поменять трансиверы на проверенные, чтобы проверить, сохраняется ли проблема.

Обновите прошивку: убедитесь, что на вашем свитче установлена последняя версия прошивки. Иногда обновления устраняют подобные ошибки.

Перезагрузите свитч: хотя это неудобно, можно запланировать техперерыв и перезагрузить свитч — это может устранить временные сбои, вызывающие предупреждение.

Проверьте логи: посмотрите логи свитча на предмет дополнительных сообщений об ошибках, которые помогут лучше понять проблему.

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

Обратитесь в техподдержку: если проблема не исчезнет, имеет смысл связаться со службой поддержки Ubiquiti для дальнейшей помощи.

Такие предупреждения нередко появляются даже при отсутствии явных проблем, но лучше перестраховаться и разобраться, чтобы избежать сбоев в сети в будущем.

Кто-нибудь ещё сталкивался с похожими проблемами или может предложить другие варианты решения этого предупреждения?

Не волнуйтесь, это не такая уж большая проблема. 4o