Всем привет!
Коллеги, обращаюсь к тем, кто плотно работает с консолью коммутаторов и оптическими линиями. Столкнулся с плавающей проблемой нестабильности оптоволоконного аплинка между двумя узлами и никак не могу до конца локализовать причину.
Кратко по топологии и оборудованию: недавно пересобирал распределительный шкаф в одном из наших корпусов. На уровне доступа трудится управляемый 24-портовый коммутатор (24 Port Switch https://serverorbit.com/network-devices/fiber-modules/24-port-en), к которому подключены рабочие станции и точки доступа, а в качестве аплинка используются комбо-порты SFP, соединенные с центральной серверной в соседнем здании (трасса около 350 метров по одномодовому волокну OS2).
В сетевые устройства с обеих сторон установлены согласованные одномодовые оптические модули (SFP fiber modules) 1.25G на 1310 нм. В течение рабочего дня при обычном офисном трафике линк держится стабильно, задержки минимальные, пинги не теряются. Но как только ночью начинается резервное копирование виртуальных машин или перенос тяжелых образов, порт на 24-портовом коммутаторе начинает «флапать» — соединение циклично падает и поднимается каждые несколько минут.
При анализе статистики интерфейса через CLI заметил несколько характерных симптомов:
Ошибки CRC на приеме: Счетчик входных ошибок (Input CRC / Frame errors) на порту коммутатора стремительно растет именно во время пиковой нагрузки, при этом на передающей стороне счетчики ошибок чистые.
Показатели DDM (Digital Diagnostic Monitoring): Запрос статуса трансивера через CLI показывает входящий уровень оптической мощности (RX Power) в диапазоне от -20.2 dBm до -21.0 dBm. Это находится прямо на граничной чувствительности приемника, тогда как уровень излучения (TX Power) на удаленном узле держится на стабильных -5 dBm.
Автосогласование: В режиме auto-negotiation порт восстанавливает линк после падения секунд за 10–15, а при принудительной фиксации скорости (1000M Full Duplex) соединение восстанавливается быстрее, но сами ошибки под нагрузкой не исчезают.
Торцы коннекторов LC на кроссах уже почистил специальным клинером, оптические патч-корды в обоих шкафах заменил на новые заведомо исправные — проблема не в локальном загрязнении разъемов.
В связи с этим пара вопросов к специалистам по оптике:
Сталкивались ли вы с ситуацией, когда оптический модуль в простое держит линк, а при длительной передаче на полной пропускной способности приемный фотодиод начинает деградировать и ловить ошибки?
Или такое пограничное затухание чаще указывает на микроизгиб или пережатие кабеля на магистральной трассе, которое дает сбой именно при максимальной нагрузке?
Буду благодарен за подсказки по дальнейшей диагностике через CLI и практический опыт!

Разбирайтесь с такими затуханиями, это не нормально. И ваша проблема скорее всего возникает именно из-за этого.
Можно начать с протирки разъемов, ну и разумеется нужен рефлектометр с нормализующей катушкой, чтоб измерить 350м.