FAQ. Опрос оборудования ZTE OLT

Оборудование ZTE OLT на шасси C220, C300, C320 имеет ряд известных проблем и еще больше пока еще неизвестных.

Проблемы заключаются в большой сложности индексов, которыми индексируются различные SNMP-таблицы. Всего существует три вида индексов (Platform composite, PON composite и zxGponOltIndex). Первые два вида могут быть разных типов. Тип указан внутри самого индекса. Для каждой комбинации шасси × версия прошивки существует свой алгоритм кодирования информации в каждом из индексов. Эта информация является засекреченой и, вероятно, так было сделано производителем намерено чтобы исключить использование сторонних систем мониторинга. Нам из открытых источников достался относительно старый документ с описаниями типов и способов кодирования, которым мы и пользовались при разработке. Во время разработы опытным путем выяснилось, что документ содержит ошибки и неточности, так что полагаться на него тоже не получилось.

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

Это подтверждено многими опытными испытаниями на различном оборудовании.

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

Удалите слоты командой:

del-card slotno 1

Сохраните конфигурацию и перезагрузите OLT.

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

Вот пример индексов интерфейсов для C3xx FW 1.2.5 (в первой версии счет полок начинается с 0):

.1.3.6.1.2.1.31.1.1.1.1.268435456 = STRING: "gpon_0/1/1"
.1.3.6.1.2.1.31.1.1.1.1.268435712 = STRING: "gpon_0/1/2"
.1.3.6.1.2.1.31.1.1.1.1.268435968 = STRING: "gpon_0/1/3"
.1.3.6.1.2.1.31.1.1.1.1.268436224 = STRING: "gpon_0/1/4"

Вот пример индексов интерфейсов для C3xx FW 2.1.0 (во второй версии счет полок начинается с 1):

.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"

Такой же результат должен быть после обновления OLT с 1.2.5 на 2.1.0.