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

Материал из WiKi - UserSide
Нет описания правки
 
(не показаны 3 промежуточные версии этого же участника)
Строка 11: Строка 11:
</pre>
</pre>


=== Особенности шасси C300 ===
=== Неверная идентификация интерфейсов ONU на шасси C320 FW v2.1.0 ===
Оборудование ZTE OLT на шасси C220, C300, C320 имеет ряд известных проблем и еще больше пока еще неизвестных.


Все что будет указано далее не имеет отношения к шасси серии C6xx (C600, C610). ZTE OLT на этом шасси известных проблем не имеет вовсе.
Если имена интерфейсов ваших ONU имеют вид <code>onu:25</code> вместо <code>epon-1/2/3:25</code>, то вам нужно настроить <code>mib-compatibility iftable v2</code> на вашем OLT. Обо всем по порядку.


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


Однако на данный момент у нас есть четкая система, которая отработана в большинстве случаев и не дает сбоев. Система заключается в реализации всех возможных комбинаций индексов и функций пересчета (перекодирования) из одного в другой. Например, при чтении SNMP-таблицы, содержащей серийные номера GPON ONU, используется индекс типа zxGponOltIndex. Этот индекс можно перекодировать в Platform composite, чтобы затем извлечь из него индекс интерфейса OLT, на котором находится данная ONU.
Вот так выглядят индексы интерфейсов при наличии проблемы (начинаются с 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. Без перезагрузки интерфейсы на этих слотах будут продолжать индексироваться по-старому.


После перезагрузки перейдите в Список подключенных ONU и перечитайте его нажав на надпись Обновить. Теперь все ONU должны быть связаны с корректными PON-портами на OLT.
==== Если вдруг это не помогло ====
В конфигурации вашего OLT вы найдете информацию о слотах наподобие этой:
В конфигурации вашего OLT вы найдете информацию о слотах наподобие этой:
<pre>
<pre>
Строка 31: Строка 52:
add-subcard rackno 1 shelfno 1 slotno 3 subcardno 1 UCDC/3
add-subcard rackno 1 shelfno 1 slotno 3 subcardno 1 UCDC/3
</pre>
</pre>
Удалите слоты командой:
 
Удалите слоты GTGO и ETGO следующей командой с указанием номера слота:
<pre>
<pre>
del-card slotno 1
del-card slotno 1
</pre>
</pre>
Сохраните конфигурацию и перезагрузите OLT.
Сохраните конфигурацию и перезагрузите OLT. При загрузке слоты будут переинициализированы и индексация PON интерфейсов теперь будет правильная.
 
 
Чтобы определить, есть ли проблема на вашем оборудовании, существует простой способ. Прочитайте SNMP таблицу .1.3.6.1.2.1.31.1.1.1.1. Индексы интерфейсов в этой таблице для шасси C300 и C320 для первой версии прошивки должны начинаться на 26, а для второй версии прошивки на 28. На самом деле индексы отличаются целиком внутренней структурой, но быстрое визуальное определение можно сделать таким простым способом. Если у вас вторая версия прошивки, но индексы начинаются на 26, то попробуйте приведенные выше рекомендации.
 
Вот пример индексов интерфейсов для C3xx FW 1.2.5:
<pre>
.1.3.6.1.2.1.31.1.1.1.1.268435456 = STRING: "gpon_1/1/1"
.1.3.6.1.2.1.31.1.1.1.1.268435712 = STRING: "gpon_1/1/2"
.1.3.6.1.2.1.31.1.1.1.1.268435968 = STRING: "gpon_1/1/3"
.1.3.6.1.2.1.31.1.1.1.1.268436224 = STRING: "gpon_1/1/4"
</pre>
 
Вот пример индексов интерфейсов для C3xx FW 2.1.0:
<pre>
.1.3.6.1.2.1.31.1.1.1.1.285278465 = STRING: "gpon_1/1/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>
Такой же результат должен быть после обновления OLT с 1.2.5 на 2.1.0.
 
=== Почему это работало раньше ===
В предыдущих версиях (по 3.18 включительно) не использовался алгоритм перекодирования индексов. Вместо этого каждый раз читалось несколько таблиц для поиска интерфейсов '''по имени'''. Так как в разных версиях прошивки счет номеров полок начинается с различных значений, то в расчет брались только два числа вместо трех: номер слота и номер порта. Это совсем неточный способ идентификации интерфейсов, к тому же требующий дополнительных операций с OLT каждый раз при чтении даже одной строки, что значительно сказывается на нагрузке на OLT и на скорости работы.
 
В новых версиях такой способ не используется. Вместо него используется перекодирование индексов, которое происходит моментально и не требует дополнительных чтений с устройства. Однако есть экземпляры ZTE C300, C320, которые имеют проблемы, пока еще успешно решаемые на стороне OLT.

Текущая версия от 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 интерфейсов теперь будет правильная.