Элтекс

Иногда возникает "подвисание", которое лечится только через "reconfigure interface gpon-port 0".
Во время этого подвисания никакие ploam/omci команды не работают, но трафик продолжает бегать. Возникает как с eltex ONU, так и со сторонними (в данном примере huawei). Возникает не со всеми ONU в дереве на тестовом стенде, а примерно с 30% случайных (остальные команды исправно принимают).

software version 3.24.1 build 107

Здравствуйте!

Включите дебаг по module pmchal: gpon, gpon-port, ont.
С помощью следующих команд:
LTP-4X# configure terminal
LTP-4X(config)# logging rsh loglevel debug
LTP-4X(config)# logging module pmchal-gpon loglevel debug
LTP-4X(config)# logging module pmchal-gpon-port loglevel debug
LTP-4X(config)# logging module pmchal-ont loglevel debug
LTP-4X(config)# do commit
LTP-4X(config)# do save

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

включение debug по вашей инструкции никаких дополнительных сообщений не дает (ни одного сообщения с префиксом debug: не вижу как в telnet, так и в serial console)

Заметил еще одну вещь: если подождать минут 5-10, то в логи выплюнется ошибка - результат вводимых команд.
При этом посылка disable-sn mode disable срабатывает через достаточно большое время.
После этого можно сделать disable-sn mode enable, и команды начнут работать:

От рассматриваемой Вами ONT 0/3 до OLT "доходит" сигнал с высоким уровнем оптической мощности. RSSI -8.5 dBm
На данном оптическом канале работает SFP модуль класса C+ 38J0-6537E-STH2+, следовательно в сторону ONT передается оптическая мощность с уровнем близким к уровню перегрузки SFP абонентского терминала.
Попробуйте уменьшить уровень мощности принимаемой/передаваемой мощности c/на ONT, хотя бы на 10 дБм.
Протестируйте управление, после уменьшения уровней.

Поставил аттенюатор, получился RX сигнал от -23 до -27 на ONU, и от -15 до 17 на OLT (я перепробовал три разных, но у них видимо затухание зависит от длины волны).

Это не сильно помогло.
Удалось установить, что ошибка возникает часто, если какую-нибудь команду примернить к "пачке" onu:


Пока все идет нормально....
Затем запрашиваем входные уровни на ONU:


И после этого порт "подвисает" на некоторое время:

vadim_kowalev писал(а):
Включите дебаг по module pmchal: gpon, gpon-port, ont.
С помощью следующих команд:
LTP-4X# configure terminal
LTP-4X(config)# logging rsh loglevel debug
LTP-4X(config)# logging module pmchal-gpon loglevel debug
LTP-4X(config)# logging module pmchal-gpon-port loglevel debug
LTP-4X(config)# logging module pmchal-ont loglevel debug
LTP-4X(config)# do commit
LTP-4X(config)# do save

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

Дополнительно к данным дебажным командам добавьте ещё

LTP-4X(config)# logging system loglevel debug

после включения дебага этой командой в режиме покоя сыплет такой лог:


я заметил команду "ontUpdateOntFwCmd", но в расписании обновления нет



после ввода команд "для зависания" - такой:

Пробовал замену SFP-модулей, пассивки, ONU-шек и самого OLT - тоже не помогло. Проблема явно не аппаратная.

Могу дать удаленный доступ на тестовую железку, сообщите в ЛС, если такой потребуется.

После обновления до 3.24.3 build 21 в логах появилось сообщение, которое как-то может пролить свет на этот баг:



Сообщения "OMCI ALARM: LAN connection established on port" на более ранних прошивках не было.

Выявил некоторые подробности:

при появлении сообщения на olt:


на терминале (huawei) пишется в логе следующее:


и так видимо на каждый omci-пакет, только CRC разные.
До первого такого сообщения все работает как надо. После - виснет gpon-порт в различных позах. Пробовал на двух разных LTP-4X revB и 6 запасных SFP, поведение одинаково.
Если выключить-включить оптику на секунду, то работа восстанавливается, порт "отвисает".

Техподдержка что-нибудь скажет? А то уже на монолог похоже

Здравствуйте! На данный момент анализируем предоставленную Вами информацию.

Вы наблюдали проявление этой проблемы только на SFP модулях класса C+ 38J0-6537E-STH2+ или также проводили тестирование SFP модулей другого вендора?
Насколько срочно Вам требуется решение этой проблемы?

На модулях другого вендора тестирование не проводил, все "C+ 38J0-6537E-STH2+", чтобы исключить битый модуль, т.к. закуплены все одинаковые.
Постараюсь взять B+ для пробы.
Решение проблемы хотелось бы увидеть в ближайший месяц.
Могу поучаствовать в тесте прошивок, если вы их мне отправите.