Базові команди перевірки стану та режимів роботи ONU на OLT BDCom P3310

У цій статті ми розглянемо базові команди з налаштування та перевірки станів ЕPON ONU з типовими параметрами: 1 PON-порт - 1 Gbps Downlink / 1 Gbps Uplink, 1 Ethernet порт - 10\100\1000 Mbps. Як оптичний термінал будемо використовувати OLT BDCom P3310 , який підтримує стандарт CTC 2.0/2.1 для віддаленого управління ONU.

Перевірка стану та режимів роботи ONU на OLT BDCom P3310B

Перед підключенням ONU до PON-гілки певного EPON SFP ознайомимося з основними станами ONU, які відбуваються після підключення:

• Registered
• Authenticated
• Auto-configuring
• Auto-configured

Перші 3 стани є не операційними, а діагностичними. За ними можна визначати, на якому етапі зупинився процес реєстрації ONU. Останній свідчить про те, що без будь-яких попередніх конфігурацій OLT самостійно автоматично зареєстрував ONU і він готовий для передачі трафіку. Можна вже сказати, що циклічне зависання на 1 зі станів і циклічне проходження перших 3-х свідчить про дві типові несправності:

1 несправність

(Найпоширеніша) На PON-гілці виникла розтяжка оптичного волокна, через що отримали критичне просідання оптичних рівнів (менше значення -30 dBm, хоча чутливість безпосередньо залежить від виробника ONU, його оптичного модуля ).

Тут же розберемо основні команди перевірки оптичних рівнів як на ONU, і на OLT. Спочатку, нам необхідно за MAC-адресою ONU визначити номер LLID (номер інтерфейсу), яким будемо до нього звертатися. Ця команда з малюнка 1 виконується з привілейованого режиму:

Рис. 1

На малюнку 2 зображено результат виконання команди, яка за інтерфейсом (LLID) виводить докладну інформацію основні показники.

Рис. 2

• operating temperature (degree): 25 - температура процесора ONU в Цельсіях
• supply voltage (V): 3.3 - напруга, що підведено до процесора ONU
• bias current (mA): 11.8 – струм зміщення лазера. Якщо коротко - рівень струму, який зараз споживає лазер (параметр не повинен швидко змінюватися, інакше це свідчить про нестабільну роботу оптичного модуля в ONU)
• transmitted power (DBm): 1.7 - значення (завжди має бути плюсова величина) оптичних рівнів, які передає ONU у бік OLT (довжина хвилі 1310нм)
• received power (DBm): -17.9 - значення (завжди має бути негативна величина) оптичних рівнів, які отримує ONU від OLT (довжина хвилі 1490нм). Саме дуже низькі показники свідчать нам про пошкодження оптичного волокна та неможливість встановлення ONU в операційний, справний режим (Auto-configured)

Наступна команда, якою можна перевірити оптичні показники:

Рис. 3

Команда, результат якої виведено малюнку 3, відбиває оптичні показники щодо OLT , тобто оптичні рівні які отримує OLT від ONU. Знаючи, що передавач ONU світить на рівнях ~ + 2dBm, можемо зараз розрахувати коефіцієнт загасання від ONU до OLT, це абсолютна різниця 2-х чисел: 2dBm – (-22.7dBm) = 24.7dB – знаходиться у задовільних межах.

Аналогічний розрахунок проводиться і для рівнів від OLT до ONU: 6.7dBm – (-17.8dBm) = 24.5dB (де + 6.7dBm рівні з передавача SFP до OLT), також задовольняє межі бюджету PON-гілки – до –30dB. Варто зауважити, що дані показники (-22.7) будуть завжди нижчими за порівнянням з рівнями від OLT до ONU, оскільки на планарних (PLC) спліттерах згасання 2-х хвиль нерівноправне, оскільки в 2-х напрямках проходять хвилі абсолютно різних довжин .

Якщо у вашій мережі показники близькі до описаних вище - це ознака того, що фізичний рівень працює нормально, стабільно і можемо переходити до інших команд перевірки і конфігураційних команд.

2 несправність

Також причиною проблем реєстрації ONU може бути несправність (у більшості випадків проявляється як нестабільна робота та недоступність певних команд із боку OLT) самого EPON SFP-модуля. Основний метод перевірки коректності роботи SFP-модуля: виконання загальної команди, яка надає звітність щодо лічильників передачі. Для канального рівня це статистика: за короткі відомості підключеного SFP-модуля, по успішно переданих кадрах, отриманих з помилкою (сортування чому кадр був відкинутий), утилізація каналу всього модуля за останні 5 хвилин. Виведення команди бачимо малюнку 4.

Рис. 4

Нас цікавить лічильник Errors – він свідчить про кількість отриманих помилок з PON-гілки. Якщо цей лічильник інтенсивно збільшується - це свідчить про дві типові проблеми:

1. Пов'язано з першим пунктом - якщо на кількох спліттерах виникло критичне просідання оптичних рівнів, що призвело до пошкодження фізичного рівня - як наслідок буде генерація багатьох пошкоджених кадрів, яку ми можемо спостерігати в даному лічильнику. Вирішення проблеми: перевірити фізичний стан лінії, виміряти прибуткові рівні на спліттерах.
   
2. Пошкодження оптичного блоку в самій SFP, PHY-розділі: за таких умов кількість помилок буде аномально збільшуватися (тисячі за секунду). Вирішення проблеми: заміна SFP.
   

Рис. 5

З чим може бути проблема і що слід перевірити – температура модуля. За аномально високої температури може спостерігатися нестабільна робота модуля у вигляді зависань зв'язків ONU (на одному з перших 3 станів або циклічний хід станів) і, відповідно, швидке зростання помилок на даному EPON-порту.

Підключимо до OLT лише 1 EPON SFP у перший epon-порт. Через 1 спліттер підключено до тесту 3 ONU. Одна з найчастіше застосовуваних команд - виведення станів всіх ONU з певною (у цьому прикладі першою) SFP:

Рис. 6

Команда з 6-го малюнка виводить короткі відомості про саму ONU, такі як марку \ модель, mac-адреса (кожна ONU має унікальну mac-адресу, яка служить тільки як ідентифікатор в PON-мережі. Дана mac-адреса не бере участі в комутації каналів).

Якщо нам заздалегідь відомий LLID (інтерфейс ONU для OLT, порядковий ідентифікатор при реєстрації обирається перший вільний у списку з 1 по 64 номер), ми можемо цією командою індивідуально перевірити статус ONU, але за особливою специфікою ОС даних OLT, двокрапку потрібно замінити на пробіл :

Рис. 7

Виведення інформації лише з певної ONU (рис. 7). Також є команди, які можна розглядати як підмножину тієї, про яку писали вище. Щоб отримати детальний висновок інформації про ONU – виконаємо наступну команду з малюнка 8:

Рис. 8

Важливий момент: більшість epon-команд мають подвоєння: варіант з "СТС" і без "СТС". CTC - це абревіатура від "China TeleCom", що є єдиним стандартизованим протоколом взаємодії OLT з ONU багатьох вендорів . Якщо в команді не вказати параметр "ctс" - команда поверне порожній результат (без помилок).

На малюнку 9 відфільтровано лише активні ONU на SFP. Але крім простого фільтра, ми отримуємо розширену інформацію про активні ONU:

Рис. 9

Найважливіші показники:

OAM Status: ctc oam oper - стандарт, за яким проходить конфігурація ONU з боку OLT, і показник того, що стан ONU операційний (активний). Інакше буде написано link fault.

LastDeregReason – останній статус причини неактивності ONU.

Alivetime – uptime ONU від останнього неактивного стану.

Розглянемо на малюнку 10 команду для перевірки всієї інформації щодо стану Ethernet порту (портів) на ONU:

Рис. 10

Команді були передані такі параметри: LLID ONU (інтерфейс ONU) та порядковий номер Ethernet-порту (в даному випадку '1' - тільки один Ethernet-порт), результат виконання команди видав докладну інформацію про статус, швидкість та дуплекс. Але не варто приймати даний перелік за стандарт - кількість значень, що виводяться, строго залежить від процесора і ПЗ самого ONU (часто висновок зупиняється тільки на статусі порту: Link-Up \ Link-Down).

Якщо дана команда не спрацьовує або дуже тривалий час відгуку - це свідчить про проблему зв'язку до самого ONU (проблема з реєстрацією \ авторизацією - вирішення проблем було описано вище). Аналогічно, якщо ви використовуєте багатопортовий ONU, для перевірки стану певного порту підставляємо як параметр його порядковий номер.

Перевірка MAC-адрес на ONU

Для цієї простої перевірки, в BDCom передбачено кілька різних за синтаксисом і результатами варіантів. Перший з них і найбільш поширений, перевірка ВСІХ (dynamic-визначені або static-) mac-адрес, отриманих з Ethernet-порту (портів) ONU. Результат команди ми бачимо малюнку 11.

Рис. 11

Ми отримали перелік усіх mac-адрес з ONU. Є один нюанс роботи деяких видів ONU - у списку отриманих mac-адрес з Ethernet-порту, крім одного реально підключеного кінцевого пристрою, може бути MAC самої ONU: це явище вважається нормальним, може змінюватися від марки \ моделі ONU.

Для того, щоб переглянути всі MAC адреси, які зараз є в mac-таблиці на ONU, виконаємо команду, яка зображена на малюнку 12:

Рис. 12

Принцип роботи цієї команди у тому, що OLT розглядає ONU як комутатор і відбиває суму всіх mac-адрес на PON порту і Ethernet порту (портах).

ВАЖЛИВО : для багатопортових ONU з боку OLT BDCom НЕ передбачено сортування mac-адрес за певними Ethernet портами - відображення виводиться як список усіх mac-адрес з усіх Ethernet-портів.

Однією з важливих команд для перевірки роботи ONU вважається віддалене перезавантаження певного порту Ethernet на ONU. Ця операція виконується з конфігураційного режиму. Для цього потрібно перейти з привілейованого режиму, виконавши команду:

#config

(Якщо у вас встановлено пароль на конфігураційний режим – введіть його)

(config)#interface epon 0/1:2

Зараз ми перебуваємо в конфігураційному режимі ONU.

(config_epon0/1:2# epon onu port 1 ctc shutdown

Виконавши цю команду, ми вимикаємо перший Ethernet (LAN) порт на ONU. В результаті після підключення крученої пари до ONU на іншій стороні не буде жодної активності. Аналогічні дії ми можемо виконати для всіх інших портів Ethernet. Щоб зафіксувати дану дію в постійній пам'яті OLT, потрібно з привілейованого режиму прописати команду:

#write

Після чого всі зміни будуть внесені до конфігураційного файлу startup-config і будуть актуальні після перезавантаження OLT.

Важливо! Ця команда є універсальною та сумісною з усіма ONU (єдиний варіант, тільки зі вставкою "Сtс"). Тому якщо після вимкнення порту він за візуальною індикацією все одно демонструє активність, а на іншій стороні спостерігаються циклічні зміни станів UP\DOWN, або фіксований режим роботи в 10 Mbps - є ймовірність, що він вийшов з ладу і не може забезпечити коректну роботу з кінцевим пристроєм .

Для скасування команди необхідно виконати її із запереченням 'no' на початку:

(config_epon0/1:2# no epon onu port 1 ctc shutdown

Виправлення проблем (Troubleshooting)

З типових проблем взаємодії OLT <-> ONU може бути варіант, коли ONU без будь-яких причин зависає в процесі реєстрації (коли перевірено що лінія в порядку і SFP-модуль працює коректно). Відсортуємо в порядку зменшення найбільш допоміжні дії для вирішення цієї проблеми:

1. Віддалене перезавантаження ONU. Виконується однією командою з привілейованого режиму двома варіантами:

#epon reboot onu mac-address

#epon reboot onu interface ePON 0/1:2

Для обох випадків потрібно підтвердити діалог відповіддю "yes" або просто "y" і натиснути Enter -> ONU перезавантажиться, з'явиться стан wire-down (індикатор обриву оптичного волокна), і далі всім відомим станам до auto-configured включно. У більшості випадків ця операція допомагає та вводить ONU в її операційний стан.

2. Фізичне перезавантаження ONU, якщо перший пункт не спрацював.

3. Видалення ONU з OLT та примусова перереєстрація ONU.

Щоб провести видалення та повторно перереєструвати ONU, потрібно перейти в привілейований режим:

#config

Після цього потрібно перейти в режим конфігурування самої epon-sfp:

(config)#interface epon 0/1

Видалимо ONU виконанням наступної команди з малюнка 13:

Рис.13

У цій команді є єдиний параметр ... sequence

Слід зазначити , що повторно перевірку стану ONU слід виконувати не за номером LLID, а перевіряючи за mac-адресою ONU. З чим це пов'язано? Тут спрацьовує логіка поширення та призначення LLID – «перший вільний». Тобто якщо попередньо був незайнятий перший інтерфейс – OLT призначить перший вільний номер.

4. (Не рекомендується для частого використання) Перезавантаження SFP-модуля. Увага - команда повністю вимикає живлення на модуль, тому зникне зв'язок з усіма підключеними ONU! Навіть при короткочасному впливі на абонентів дане переривання буде помітним!

Для цього потрібно перейти в привілейований режим, з нього в конфігураційний та короткочасно вимкнути модуль. Розглянемо це у вигляді послідовності команд:

#config

(config)#interface ePON 0/1

(config_epon0/1)#shutdown

(config_epon0/1)#no shutdown

На закінчення, стан усіх ONU стане wire-down. Дійсно підтверджується як раптове відключення від мережі, оскільки сигнал OAM Dying Gasp (сигналізує фізичне відключення ONU з лінії живлення) не міг бути переданий від ONU до OLT. Якщо після виконаного проблемний ONU вийшов на зв'язок (стан auto-configured) - слід відразу перевірити оптичні рівні від ONU і від OLT. Якщо вони в межах норми, потрібно проаналізувати, чи виникає подібна ситуація з іншими ONU, особливо на тих же спліттерах. Якщо індивідуальна проблема - можна припустити, що несправність саме з ONU і необхідна заміна.