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

Настройка 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

Особенности шасси C300

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

Все что будет указано далее не имеет отношения к шасси серии C6xx (C600, C610). ZTE OLT на этом шасси известных проблем не имеет вовсе.

Проблемы заключаются в большой сложности индексов, которыми индексируются различные 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:

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

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

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

Почему это работало раньше

В предыдущих версиях (по 3.18 включительно) не использовался алгоритм перекодирования индексов. Вместо этого каждый раз читалось несколько таблиц для поиска интерфейсов по имени. Так как в разных версиях прошивки счет номеров полок начинается с различных значений, то в расчет брались только два числа вместо трех: номер слота и номер порта. Это совсем неточный способ идентификации интерфейсов, к тому же требующий дополнительных операций с OLT каждый раз при чтении даже одной строки, что значительно сказывается на нагрузке на OLT и на скорости работы.

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