FAQ. Опрос оборудования ZTE OLT: различия между версиями

Материал из WiKi - UserSide
Нет описания правки
Нет описания правки
 
(не показано 9 промежуточных версий этого же участника)
Строка 1: Строка 1:
Оборудование ZTE OLT на шасси C220, C300, C320 имеет ряд известных проблем и еще больше пока еще неизвестных.
=== Настройка SNMP ===
По умолчанию OLT не отдает по SNMP все необходимые разделы. Их нужно включить.
<pre>
snmp-server community КОМЬЮНИТИ view allview rw
snmp-server view allview org included
snmp-server view allview internet included
snmp-server view allview mgmt included
snmp-server view allview mib-2 included
snmp-server view allview system included
snmp-server view DefaultView system included
</pre>
 
=== Неверная идентификация интерфейсов ONU на шасси C320 FW v2.1.0 ===


Проблемы заключаются в большой сложности индексов, которыми индексируются различные SNMP-таблицы. Всего существует три вида индексов (Platform composite, PON composite и zxGponOltIndex). Первые два вида могут быть разных типов. Тип указан внутри самого индекса. Для каждой комбинации <code>шасси × версия прошивки</code> существует свой алгоритм кодирования информации в каждом из индексов. Эта информация является засекреченой и, вероятно, так было сделано производителем намерено чтобы исключить использование сторонних систем мониторинга. Нам из открытых источников достался относительно старый документ с описаниями типов и способов кодирования, которым мы и пользовались при разработке. Во время разработы опытным путем выяснилось, что документ содержит ошибки и неточности, так что полагаться на него тоже не получилось.
Если имена интерфейсов ваших ONU имеют вид <code>onu:25</code> вместо <code>epon-1/2/3:25</code>, то вам нужно настроить <code>mib-compatibility iftable v2</code> на вашем OLT. Обо всем по порядку.


Однако на данный момент у нас есть четкая система, которая отработана в большинстве случаев и не дает сбоев. Система заключается в реализации всех возможных комбинаций индексов и функций пересчета (перекодирования) из одного в другой. Например, при чтении SNMP-таблицы, содержащей серийные номера GPON ONU, используется индекс типа zxGponOltIndex. Этот индекс можно перекодировать в Platform composite, чтобы затем извлечь из него индекс интерфейса OLT, на котором находится данная ONU.
==== Диагностика проблемы. ====
Находясь в карточке вашего OLT в USERSIDE перейдите внизу слева по ссылке "Список интерфейсов". Если вы видите интерфейсы, индексы которых начинаются с '''26...''', то проблема присутствует.


Это подтверждено многими опытными испытаниями на различном оборудовании.
Вот так выглядят индексы интерфейсов при наличии проблемы (начинаются с 26...):
<pre>
.1.3.6.1.2.1.31.1.1.1.1.268500992 = gpon_1/2/1
.1.3.6.1.2.1.31.1.1.1.1.268501248 = gpon_1/2/2
.1.3.6.1.2.1.31.1.1.1.1.268501504 = gpon_1/2/3
</pre>
 
Вот так должны выглядеть индексы интерфейсов (начинаются с 28...):
<pre>
.1.3.6.1.2.1.31.1.1.1.1.285278721 = gpon_1/2/1
.1.3.6.1.2.1.31.1.1.1.1.285278722 = gpon_1/2/2
.1.3.6.1.2.1.31.1.1.1.1.285278723 = gpon_1/2/3
</pre>
 
==== Решение проблемы ====
Решить данную проблему можно установив правильный режим (v2) индексации интерфейсов.
В CLI вашего OLT добавьте в конфигурацию следующую команду:
<pre>
mib-compatibility iftable v2
</pre>
После выполнения этой команды снова прочитайте "Список интерфейсов" из карточки оборудования. Теперь индексы интерфейсов должны начинаться с 28..., как показано выше в примере. Если получилось, теперь перейдите в Редактировать - Настройка интерфейсов/стекирования и нажмите "Сохранить" в списке интерфейсов. После этого убедитесь, что индексация в этой настройке изменилась на новую.


Однако есть определенный, довольно значимый процент оборудования ZTE OLT на шасси C300 и C320, которое ведет себя некорректно. Чаще всего это проявляется в несовпадении индексов. Мы знаем (и в документации это сказано) как должны кодироваться индексы для шасси C320 для прошивки v2.1.0, но бывает оборудование, в котором индексы интерфейсов закодированы как в первой версии прошивки. Вероятно это возникает после обновления OLT с 1 на 2 версии прошивки, мы этого точно не знаем. Эту проблему невозможно исправить на нашей стороне, так как мы подбираем алгоритм преобразования индексов согласно комбинации <code>шасси × версия прошивки</code>. Единственный вариант решения этой проблемы сейчас - это удаление слотов из конфигурации, сохранение конфигурации и перезагрузка OLT. Вероятно после этой процедуры во время загрузки OLT переинициализирует слоты заново и их индексирование становится корректным.
Чтобы переинициализировались слоты GTGO и ETGO, нужно перезагрузить OLT. Без перезагрузки интерфейсы на этих слотах будут продолжать индексироваться по-старому.


Чтобы определить, есть ли проблема на вашем оборудовании, существует простой способ. Прочитайте SNMP таблицу .1.3.6.1.2.1.31.1.1.1.1. Индексы интерфейсов в этой таблице для шасси C300 и C320 для первой версии прошивки должны начинаться на 26, а для второй версии прошивки на 28. На самом деле индексы отличаются целиком внутренней структурой, но быстрое визуальное определение можно сделать таким простым способом. Если у вас вторая версия прошивки, но индексы начинаются на 26, то попробуйте приведенные выше рекомендации.
После перезагрузки перейдите в Список подключенных ONU и перечитайте его нажав на надпись Обновить. Теперь все ONU должны быть связаны с корректными PON-портами на OLT.


Вот пример индексов интерфейсов для C3xx FW 1.2.5 (в первой версии счет полок начинается с 0):
==== Если вдруг это не помогло ====
В конфигурации вашего OLT вы найдете информацию о слотах наподобие этой:
<pre>
<pre>
.1.3.6.1.2.1.31.1.1.1.1.268435456 = STRING: "gpon_0/1/1"
add-rack rackno 1 racktype C320Rack
.1.3.6.1.2.1.31.1.1.1.1.268435712 = STRING: "gpon_0/1/2"
add-shelf rackno 1 shelfno 1 shelftype C320_SHELF
.1.3.6.1.2.1.31.1.1.1.1.268435968 = STRING: "gpon_0/1/3"
add-card rackno 1 shelfno 1 slotno 1 GTGO
.1.3.6.1.2.1.31.1.1.1.1.268436224 = STRING: "gpon_0/1/4"
add-subcard rackno 1 shelfno 1 slotno 3 subcardno 1 UCDC/3
</pre>
</pre>


В то время как тот же OLT после корректного обновления на прошивку 2.1.0 должен иметь следующие индексы:
Удалите слоты GTGO и ETGO следующей командой с указанием номера слота:
<pre>
<pre>
.1.3.6.1.2.1.31.1.1.1.1.285278465 = STRING: "gpon_1/1/1"
del-card slotno 1
.1.3.6.1.2.1.31.1.1.1.1.285278466 = STRING: "gpon_1/1/2"
.1.3.6.1.2.1.31.1.1.1.1.285278467 = STRING: "gpon_1/1/3"
.1.3.6.1.2.1.31.1.1.1.1.285278468 = STRING: "gpon_1/1/4"
</pre>
</pre>
Сохраните конфигурацию и перезагрузите OLT. При загрузке слоты будут переинициализированы и индексация PON интерфейсов теперь будет правильная.

Текущая версия от 14:03, 31 июля 2024

Настройка SNMP

По умолчанию OLT не отдает по SNMP все необходимые разделы. Их нужно включить. 

snmp-server community КОМЬЮНИТИ view allview rw
snmp-server view allview org included
snmp-server view allview internet included
snmp-server view allview mgmt included
snmp-server view allview mib-2 included
snmp-server view allview system included
snmp-server view DefaultView system included

Неверная идентификация интерфейсов ONU на шасси C320 FW v2.1.0

Если имена интерфейсов ваших ONU имеют вид onu:25 вместо epon-1/2/3:25, то вам нужно настроить mib-compatibility iftable v2 на вашем OLT. Обо всем по порядку.

Диагностика проблемы.

Находясь в карточке вашего OLT в USERSIDE перейдите внизу слева по ссылке "Список интерфейсов". Если вы видите интерфейсы, индексы которых начинаются с 26..., то проблема присутствует.

Вот так выглядят индексы интерфейсов при наличии проблемы (начинаются с 26...): 

.1.3.6.1.2.1.31.1.1.1.1.268500992 = gpon_1/2/1
.1.3.6.1.2.1.31.1.1.1.1.268501248 = gpon_1/2/2
.1.3.6.1.2.1.31.1.1.1.1.268501504 = gpon_1/2/3

Вот так должны выглядеть индексы интерфейсов (начинаются с 28...): 

.1.3.6.1.2.1.31.1.1.1.1.285278721 = gpon_1/2/1
.1.3.6.1.2.1.31.1.1.1.1.285278722 = gpon_1/2/2
.1.3.6.1.2.1.31.1.1.1.1.285278723 = gpon_1/2/3

Решение проблемы

Решить данную проблему можно установив правильный режим (v2) индексации интерфейсов. В CLI вашего OLT добавьте в конфигурацию следующую команду: 

mib-compatibility iftable v2

После выполнения этой команды снова прочитайте "Список интерфейсов" из карточки оборудования. Теперь индексы интерфейсов должны начинаться с 28..., как показано выше в примере. Если получилось, теперь перейдите в Редактировать - Настройка интерфейсов/стекирования и нажмите "Сохранить" в списке интерфейсов. После этого убедитесь, что индексация в этой настройке изменилась на новую.

Чтобы переинициализировались слоты GTGO и ETGO, нужно перезагрузить OLT. Без перезагрузки интерфейсы на этих слотах будут продолжать индексироваться по-старому.

После перезагрузки перейдите в Список подключенных ONU и перечитайте его нажав на надпись Обновить. Теперь все ONU должны быть связаны с корректными PON-портами на OLT.

Если вдруг это не помогло

В конфигурации вашего OLT вы найдете информацию о слотах наподобие этой: 

add-rack rackno 1 racktype C320Rack
add-shelf rackno 1 shelfno 1 shelftype C320_SHELF
add-card rackno 1 shelfno 1 slotno 1 GTGO
add-subcard rackno 1 shelfno 1 slotno 3 subcardno 1 UCDC/3

Удалите слоты GTGO и ETGO следующей командой с указанием номера слота: 

del-card slotno 1

Сохраните конфигурацию и перезагрузите OLT. При загрузке слоты будут переинициализированы и индексация PON интерфейсов теперь будет правильная.

Источник — https://wiki.userside.eu/index.php?title=FAQ._Опрос_оборудования_ZTE_OLT&oldid=19283