Элтекс
производство оборудования для телекоммуникаций
DRIFT_OF_WINDOW_ONUi
DRIFT_OF_WINDOW_ONUi
Сообщение head » 27 май 2016 13:39
Re: DRIFT_OF_WINDOW_ONUi
Сообщение head » 27 май 2016 13:40
Re: DRIFT_OF_WINDOW_ONUi
Сообщение head » 30 май 2016 15:52
Re: DRIFT_OF_WINDOW_ONUi
Сообщение shabaev_av » 02 июн 2016 11:13
Re: DRIFT_OF_WINDOW_ONUi
Сообщение Dirks G » 03 июн 2016 16:42
Re: DRIFT_OF_WINDOW_ONUi
Сообщение shabaev_av » 06 июн 2016 11:45
Re: DRIFT_OF_WINDOW_ONUi
Сообщение Dirks G » 09 июн 2016 10:29
Re: DRIFT_OF_WINDOW_ONUi
Сообщение MapcuaHKa » 22 авг 2016 15:27
Вопрос следующий:
Есть 2 OLT LTP-8x, в логах периодически всплывают записи pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi от разных абонентов, нам что всю оптику переваривать? или все абонентские NTU менять?:) Насколько критичны эти ошибки с текущим временным интервалом (в смысле не частые)?
1) Eltex LTP-8X:rev.B software version 3.24.0 build 4385:
LTP-8X# show log grep DRIFT
Jan 4 04:21:36 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/0]
Jan 4 06:44:12 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/2]
Jan 4 07:26:28 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/4]
Jan 4 07:35:32 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/1]
Jan 4 07:54:35 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/3]
Jan 4 07:58:03 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/3]
Jan 4 11:14:35 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/0]
Jan 4 17:16:27 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/1]
Jan 4 17:55:12 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/3]
Jan 4 17:55:21 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/0]
Jan 4 17:56:20 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/3]
Jan 4 17:56:49 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/2]
Jan 4 19:07:27 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/0]
Jan 4 22:08:49 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/2]
Jan 4 22:10:57 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/1]
Jan 4 22:11:11 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/3]
Jan 4 22:11:41 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/2]
Jan 5 02:22:47 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/2]
Jan 5 02:25:12 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/3]
Jan 5 02:53:50 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/1]
Jan 5 05:16:54 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/3]
Jan 5 05:16:59 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/0]
Jan 5 05:19:46 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/2]
Jan 5 06:29:42 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/4]
Jan 5 10:12:20 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/2]
Jan 5 18:00:19 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/2]
Jan 5 19:05:25 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT7/0]
Jan 5 19:57:41 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/3]
Jan 5 20:08:22 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT6/2]
2) Eltex LTP-8X:rev.C software version 3.26.0 build 7201:
LTP-8X# show log grep DRIFT
Jan 1 05:10:24 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/5]
Jan 1 07:04:17 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/4]
Jan 1 07:39:36 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/3]
Jan 1 07:41:08 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/2]
Jan 1 14:10:21 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/6]
Jan 1 14:10:22 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/5]
Jan 1 21:16:06 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/6]
Jan 1 21:47:27 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/5]
Jan 2 00:23:10 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/3]
Jan 2 00:24:13 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/2]
Jan 2 00:27:15 LTP-8X pmchal: notice: [GPON] PON ALARM: DRIFT_OF_WINDOW_ONUi from [ONT0/4]
Может ли быть проблема не только в ONT или оптическом кабеле, а с SFP-модулями в OLT может быть проблема?
Настройка Syslog и SNMP trap по событию Dying Gasp
Технология «Dying gasp» позволяет проинформировать администратора сети при отключении питания от коммутатора через отправку syslog сообщения или snmp-trap, а также с помощью пакетов ethernet OAM.
Если коммутатор аппаратно поддерживает технологию «Dying gasp», то есть возможность настроить отправку сообщения по протоколу syslog или snmp trap в момент отключения электропитания от устройства.
Информация о том, какие устройства аппаратно поддерживают Dying gasp, можно найти в «Руководстве пользователя» в таблице 9 – Основные технические характеристики.
1) Настраиваем SYSLOG сервер на устройстве. В примере используется настройка для local 0, severity от 1 до 7
console(config)# logging-server 128 ipv4 192.168.2.2
console(config)# logging-server 129 ipv4 192.168.2.2
console(config)# logging-server 130 ipv4 192.168.2.2
console(config)# logging-server 131 ipv4 192.168.2.2
console(config)# logging-server 132 ipv4 192.168.2.2
console(config)# logging-server 133 ipv4 192.168.2.2
console(config)# logging-server 134 ipv4 192.168.2.2
console(config)# logging-server 135 ipv4 192.168.2.2
2) Настраиваем отправку SNMP trap. Community private, сервер 192.168.2.2
console(config)# snmp user SimpleUser
console(config)# snmp community index 1 name private security SimpleUser
console(config)# snmp group SimpleGroup user SimpleUser security-model v2c
console(config)# snmp access SimpleGroup v2c read iso write iso notify iso
console(config)# snmp view iso 1 included
console(config)# snmp targetaddr SimpleHost param SimpleParams 192.168.2.2 taglist SimpleTag
console(config)# snmp targetparams SimpleParams user SimpleUser security-model v2c message-processing v2c
console(config)# snmp notify SimpleNotify tag SimpleTag type Trap
3) Для отправки информации по Dying gasp необходимо обязательно настроить OAM на порту
console(config)# set ethernet-oam enable
console(config)# interface gigabitethernet 0/2
console(config-if)# ethernet-oam enable
Dying gasp что это
When ONT goes offline then Huawei OLT receives a message from ONT then system generates dying gasp alarm. If power cord remove from ONT without power off ONT device or Load shedding causes electricity power go away then system generates dying gasp alarm.
Attribute:
Dying gasp Alarm GPON Huawei ONTi (DGi)
Parameters:
| Name | Meaning |
|---|---|
| FrameID | The ID of the shelf where the alarm is generated. |
| SlotID | The ID of the slot where the alarm is generated. |
| PortID | The ID of the port where the alarm is generated. |
| ONT ID | The ID of the ONT where the alarm is generated. |
| Equipment ID | The ID of the equipment where the alarm is generated. |
| Description of the ONT(Only for NMS) | The description of the ONT (only available on the NMS), which can be used to distinguish different ONTs. |
Impact on the System:
The services of the ONT are interrupted.
Possible Causes:
The power of the ONT is abnormal or the ONT is shut down.
Procedure:
Related Information:
The Optical Network Unit (ONU) and the Optical Network Terminal (ONT) are both the user-side devices of the Optical Line Terminal (OLT) and they are both referred to as ONT.
The dying-gasp of GPON ONTi (DGi) is generated
Related clear alarm: 0x2e12a00b The dying-gasp of GPON ONTi (DGi) recovers
Базовые команды проверки состояния и режимов работы ONU на OLT BDCom P3310
Проверка состояния и режимов работы ONU на OLT BDCom P3310B
Перед подключением ONU к PON-ветке определенного EPON SFP ознакомимся с основными состояниями ONU, которые проходят после подключения:
Первые 3 состояния являются не операционными, а диагностическими. По ним можно определять на каком этапе остановился процесс регистрации ONU. Последний свидетельствует о том, что без всяких предварительных конфигураций OLT самостоятельно, автоматически зарегистрировал ONU и он готов для передачи трафика. Можно уже сказать, что циклическое зависания на 1 из станов и циклическое прохождение первых 3-х свидетельствует о двух типичных неисправностях:
Здесь же разберем основные команды для проверки оптических уровней как на ONU, так и на OLT. Сначала, нам необходимо по MAC-адресу ONU определить номер LLID (номер интерфейса), по которому будем в дальнейшем к нему обращаться. Данная команда из рисунка 1 выполняется с привилегированного режима:
На рисунке 2 изображено результат выполнения команды, которая по интерфейсу (LLID) выводит подробную информацию за основные показатели.
Следующая команда, которой можно проверить оптические показатели:
Команда, результат которой выведено на рисунке 3, отражает оптические показатели уже относительно OLT, то есть оптические уровни которые получает OLT от ONU. Зная, что передатчик ONU светит на уровнях
2 неисправность
Также причиной проблем регистрации ONU может быть неисправность (в большинстве случаев проявляется как нестабильная работа и недоступность определенных команд из стороны OLT) самого EPON SFP-модуля. Основной метод проверки корректности работы SFP-модуля: выполнение общей команды, которая предоставляет отчетность по счетчикам передачи данных. Для канального уровня это статистика: за краткие сведения подключенного SFP-модуля, по успешно переданных кадрах, полученных с ошибкой (cортировка по какой причине кадр был отброшен), утилизация канала всего модуля за последние 5 минут. Вывод команды видим на рисунке 4.
Команда из 6-го рисунка выводит краткие сведения о самой ONU, такие как марку \ модель, mac-адрес (каждая ONU обладает уникальным mac-адресом, который служит только как идентификатор в PON-сети. Данный mac-адрес НЕ участвует в коммутации каналов).
Если нам заранее известен LLID (интерфейс ONU для OLT, порядковый идентификатор при регистрации, избирается первый свободный в списке с 1 по 64 номер), мы можем данной командой индивидуально проверить статус ONU, но по особой специфике ОС данных OLT, двоеточие нужно заменить на пробел:
На рисунке 9 отфильтровано только активные ONU на SFP. Но кроме простого фильтра, мы получаем расширенную информацию об активных ONU:
Наиболее важные показатели:
Рассмотрим на рисунке 10 команду для проверки всей информации по состоянию Ethernet порта (портов) на ONU:
Проверка MAC-адресов на ONU
Для этой простой проверки, в BDCom предусмотрено несколько, разных по синтаксису и результатах, вариантов. Первый из них и наиболее распространенный, проверка ВСЕХ (dynamic-определены или static-) mac-адресов, полученных с Ethernet-порта (портов) ONU. Результат команды мы видим на рисунке 11.
Для того, чтобы просмотреть все MAC адреса, которые сейчас есть в mac-таблице на ONU выполним команду, которая изображена на рисунке 12:
Принцип работы данной команды заключается в том, что OLT рассматривает ONU как коммутатор и отражает сумму всех mac-адресов на PON порту и на Ethernet порту (портах).
Одной из важных команд для проверки работы ONU считается удаленная перезагрузка определенного Ethernet порта на ONU. Данная операция выполняется из конфигурационного режима. Для этого нужно перейти с привилегированного режима, выполнив команду:
(config)#interface epon 0/1:2
Сейчас мы находимся в конфигурационном режиме самого ONU.
(config_epon0/1:2# epon onu port 1 ctc shutdown
Выполнив данную команду мы выключаем первый Ethernet (LAN) порт на ONU. В результате после подключения витой пары к ONU на другой стороне не будет никакой активности. Аналогичные действия мы можем выполнить для всех остальных Ethernet портов. Чтобы зафиксировать данное действие в постоянной памяти OLT нужно с привилегированного режима прописать команду:
После чего все изменения будут внесены в конфигурационный файл startup-config, и будут актуальны после перезагрузки OLT.
Для отмены команды необходимо выполнить ее с отрицанием ‘no’ в начале:
(config_epon0/1:2# no epon onu port 1 ctc shutdown
Исправление проблем (Troubleshooting)
Из типичных проблем взаимодействия OLT ONU может быть вариант, когда ONU без всяких на то причин зависает в процессе регистрации (когда проверено что линия в порядке и SFP-модуль работает корректно). Отсортируем в порядке убывания наиболее вспомогательные действия для решения этой проблемы:
1. Удаленная перезагрузка ONU. Выполняется одной командой с привилегированного режима 2-мя вариантами:
#epon reboot onu mac-address
#epon reboot onu interface ePON 0/1:2
2. Физическая перезагрузка ONU, если первый пункт не сработал.
3. Удаление ONU с OLT и принудительная перерегистрация ONU.
Чтобы провести удаление и повторно перерегистрировать ONU нужно перейти в привилегированный режим:
После чего нужно перейти в режим конфигурирования самой epon-sfp:
(config)#interface epon 0/1
Удалим ONU выполнением следующей команды из рисунка 13:
The Dying Gasp
By Emet-Selch’s own words, you are no one─nothing─your life a ghastly mockery of past perfection, utterly devoid of meaning. Yet despite his endless refutations of your worth, mankind has dreamed and struggled and survived. Even now, you fight to preserve your future, and spare two worlds from unimaginable destruction.
The moment has come to make your stand, to call upon every last reserve of strength. Fight for those who shared your journey, and for those you met along the way. Fight for those who awaited your coming across the boundaries of time and space. From distant stars yet undimmed, you are joined by seven summoned champions, for only together can you hope to prevail against the staggering might of this ancient Ascian─the immortal and implacable Hades!
The Dying Gasp is a level 80 trial introduced in patch 5.0 with Shadowbringers.
Contents
Phases & Abilities
Ascian: Hades
Ascian: Hades Your encounter with Emet-Selch (Hades) takes place within a circular arena overlooking the ruins of Amaurot, deep within the Tempest. Thanks to a small outer railing during the opening phase, players will be incapable of falling over the edge. However, the railing will eventually be destroyed as the fight progresses, meaning players can plummet to their doom if they stray too far. However, there are no notable knockback or movement-based attacks to consider at the time.
Below is a list of all Hades’ abilities and phases.
Phase 1
From here on, Hades will begin to cycle the previously utilized abilities (possibly with overlapped combinations) until his health has been reduced to 10%. Once sufficiently damaged, Hades will become untargetable while an add-phase begins.
Add Phase
Whilst invulnerable, five waves of Ancients (adds) will be summoned into the arena. Simultaneously, a Fervor of the Ancients (Duty Guage) will slowly begin to fill-up, indicating Hades growing power. If the adds are not defeated before Fervor of the Ancients reaches 100 (max), the raid will be wiped.
With Hades now in full form, the fight resumes with the arena shrouded in darkness and lacking the outer railing, meaning players can accidentally walk over the edge to their doom if not careful. Throughout the rest of the encounter, Hades will no longer be moveable, remaining rooted to the north of the arena with a much larger non-directional hit-box. Whilst in this form, the target with highest enmity (typically the tank) will be constantly peppered by ranged auto-attacks in-between all other mechanics, so beware.
At this point, Hades will begin to loop the above mechanics with increased overlap until he has been brought to around 20% health.
The Finale
Once Hades has been sufficiently damaged, he will eventually chain all players via Life In Captivity, rendering them unable to move or act. After beseeching aid from his fallen brethren and calling upon the darkness once more, an Active Time Maneuver will commence. Much like most other active time maneuvers, players must continuously press buttons to fill up a meter before a timer runs out. If successful, the player will break free of their chains in a blaze of overflowing light, much to the chagrin of Hades, who curses Hydaelyn before his last-ditch effort to thwart the raid. However, should any player fail to fill the gauge during the active time maneuver, they will be instantly KO’d instead.
