Элтекс

может в практике сталкивались

Несколько дней пытаемся победить нашу проблему:

На районе в достаточно компактном куске территории хаотично отключаются ONT NTE-2 B+, таких проблемных около 10-12 шт. ( используем LTE-8x, на текущий момент на ней около 100 абонентов)
на порту примерно 20-25 абонентов, меняли модуль , меняли порт olt результата нет.
Несмотря на компактное местоположение (7 проблемных абонентов находятся на одном уровне в пределах одного вышестоящего сплиттера) другие абоненты с этого куска карты в разных портах PON

Уровень сигнала вполне рабочий. Не идеальный конечно, но грубо говоря на том же сплиттере сидят абоненты которые вообще не испытывают проблем с точно таким же сигналом. есть другая olt с такими же уровнями сигнала там такой проблемы нет.

Дальше интересный факт. Берем новую онт, ставим ее абоненту она включается и работает, ту что сняли с абонента несем к соседнему проблемному абоненту она у него работает. Но спустя какое то время вся эта свистопляска начинается заново.

Некоторые абоненты ночью начинают работать и к обеду отключаются. Некоторые наоборот.

т.е. никакой системы кроме куска карты с радиусом в метров 300


Была версия по качеству питания (низкое напряжение например, и вполне подходило под версию расположение на одной линии столбов, тем более что похолодало и многие стали обогреваться электричеством), на удивление замеры показали что в розетках почти идеальное напряжение.

В логах выглядит примерно вот так:

Nov 19 16:17:11 OLT-03 chip-proxy: alarm_oltlink: 02:00:5E:01:D4:3D (desc: 3kooperativnaya_30) in REPORTTIMEOUT state
Nov 19 16:17:11 OLT-03 chip-proxy: alarm_oltlink: 02:00:5E:01:D4:3C (desc: 3kooperativnaya_30) in REPORTTIMEOUT state
Nov 19 16:17:11 OLT-03 chip-proxy: alarm_oltlink: 02:00:5E:01:D4:3E (desc: 3kooperativnaya_30) in REPORTTIMEOUT state
Nov 19 16:17:11 OLT-03 chip-proxy: alarm_oltlink: 02:00:5E:01:D4:3F (desc: 3kooperativnaya_30) in REPORTTIMEOUT state
Nov 19 16:17:11 OLT-03 chip-proxy: ONT 02:00:5E:01:D4:3C (desc: 3kooperativnaya_30) disconnected (OLT3[0])
Nov 19 16:20:57 OLT-03 chip-proxy: alarm_oltlink: 02:00:5E:01:70:5C (desc: 1kooperativnaya40) in REPORTTIMEOUT state
Nov 19 16:20:57 OLT-03 chip-proxy: alarm_oltlink: 02:00:5E:01:70:5F (desc: 1kooperativnaya40) in REPORTTIMEOUT state
Nov 19 16:20:57 OLT-03 chip-proxy: alarm_oltlink: 02:00:5E:01:70:5D (desc: 1kooperativnaya40) in REPORTTIMEOUT state
Nov 19 16:20:57 OLT-03 chip-proxy: alarm_oltlink: 02:00:5E:01:70:5E (desc: 1kooperativnaya40) in REPORTTIMEOUT state
Nov 19 16:20:57 OLT-03 chip-proxy: ONT 02:00:5E:01:70:5C (desc: 1kooperativnaya40) disconnected (OLT3[0])
Nov 19 16:27:50 OLT-03 chip-proxy: ONT 02:00:5E:01:D4:3C is allocated by link 02:00:5E:01:D4:3C
Nov 19 16:27:55 OLT-03 chip-proxy: ONT 02:00:5E:01:D4:3C (desc: 3kooperativnaya_30) configure ok

Какая прошивка олта?
Какие уровни?
Какой конфиг пон чипа?
Какой конфиг ону?

Добрый день.
denaie, вы присылали запрос на почту ТП 19.11. В ответном письме у вас была запрошена дополнительная информация, но ответа не последовало.
Если ситуация с отваливание ONT сохраняется, для анализа потребуется:
- полный log-файл с LTE-8X.
- информация по состоянию всех ONT. Команда: LTE-8X# show ont list verbose all
- версия ПО LTE-8Х. Команда: LTE-8X# show version
- информация по всем olt-чипам
LTE-8X# olt 0
LTE-8X(OLT0)# show port state
и так по всем чипам olt

на текущий момент ситуация более менее локализована.

Что нашли. Если смотреть сигнал на онт то они показывают что он идеальный 28-27, а в реальности он 34 при измерении измерителем мощности пон.
По факту где то проблема в кабеле, но на улице минус 40 и что то делать сейчас нереально. Где сомгли переключили на другую ветку где сигнал лучше и будем ждать потепления и разбираться

Началась аналогичная проблема. Часть абонентов отваливается и снова авторизуется, хотя затухание нормальное. Что на измерителе, что на OLT.

Логи


ont list


Прошивка на голове последняя как и на 1402.

На измерителе вообще -19 показывает...

Модули С++ на olt. Куда копнуть?

Добрый день.
Эта часть отваливающихся абонентов находится на одном дереве pon?

churin писал(а):Добрый день.
Эта часть отваливающихся абонентов находится на одном дереве pon?

Здравствуйте. Часть на одном дереве, часть на другом.


На дату не смотрим. По NTP голова не синхронизируется с сервером времени...

Trider писал(а):

churin писал(а):Добрый день.
Эта часть отваливающихся абонентов находится на одном дереве pon?

Здравствуйте. Часть на одном дереве, часть на другом.

На дату не смотрим. По NTP голова не синхронизируется с сервером времени...

Отправьте полный log c LTE на почту 3211@eltex.org
Также приведите вывод команд:

Собственно к какому заключению я пришел.

52 ветка глючная, сейчас объясню почему.

На 52 ветке у меня постоянно отваливались приставки 1402G-W rev. B по REPORTTIMEOUT, причем с разных портов, что с 0, что с 1.
В текущий момент я в мониторинге не вижу ничего критичного, как было пару дней назад на 52 ветке.

Еще, всем советую включить FEC, довольно хорошая штука о которой я не знал. Плюс отключить в Layer 3, ARP Snoping и RARP Snooping, контролируя все на ядре или вышестоящем коммутаторе за LTE.

Откатиться до 3.14.4.9, что я успешно и сделал в ночь и сейчас аптайм сессий на брасе 1d05h, а до этого на 52 ветке был расколбас каждые 5 минут.

Насчет DNS на 1402G-W rev. B, я говорил сотрудникам Элтекса, что нужно решать данный вопрос, т.к. по динамике он напрочь не работает!

Как вышел из ситуации (временно), сократил время аренды до 3 минут, хотя это не правильно!

Решите уже вопросы данные, товарищи разработчики!