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

Версия от 09:11, 30 июля 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..., как показано выше в примере.

Если не сработало

В конфигурации вашего 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. При загрузке слоты будут переинициализированы.

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

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

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

@@ Строка 11: / Строка 11: @@
 </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>
-Однако есть определенный, довольно значимый процент оборудования ZTE OLT на шасси C300 и C320, которое ведет себя некорректно. Чаще всего это проявляется в несовпадении индексов. Мы знаем (и в документации это сказано) как должны кодироваться индексы для шасси C320 для прошивки v2.1.0, но бывает оборудование, в котором индексы интерфейсов закодированы как в первой версии прошивки. Вероятно это возникает после обновления OLT с 1 на 2 версии прошивки, мы этого точно не знаем. Эту проблему невозможно исправить на нашей стороне, так как мы выбираем алгоритм преобразования индексов согласно комбинации <code>шасси × версия прошивки</code>. Единственный вариант решения этой проблемы сейчас — это удаление слотов из конфигурации, сохранение конфигурации и перезагрузка OLT. Вероятно после этой процедуры во время загрузки OLT переинициализирует слоты заново и их индексирование становится корректным. Не забывайте о резервной копии перед подобными действиями.
+==== Решение проблемы ====
+Решить данную проблему можно установив правильный режим (v2) индексации интерфейсов.
+В CLI вашего OLT добавьте в конфигурацию следующую команду:
+<pre>
+mib-compatibility iftable v2
+</pre>
+После выполнения этой команды снова прочитайте "Список интерфейсов" из карточки оборудования. Теперь индексы интерфейсов должны начинаться с 28..., как показано выше в примере.
+==== Если не сработало ====
 В конфигурации вашего OLT вы найдете информацию о слотах наподобие этой:
 <pre>
@@ Строка 35: / Строка 52: @@
 del-card slotno 1
 </pre>
-Сохраните конфигурацию и перезагрузите OLT.
+Сохраните конфигурацию и перезагрузите OLT. При загрузке слоты будут переинициализированы.
-Чтобы определить, есть ли проблема на вашем оборудовании, существует простой способ. Прочитайте 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.
 === Почему это работало раньше ===