FAQ. Опрос оборудования ZTE OLT - История изменений

N.Skrypnik в 09:02, 12 мая 2025

2025-05-12T09:02:00Z

← Предыдущая версия		Версия от 09:02, 12 мая 2025
Строка 1:		Строка 1:
			[[FAQ._ZTE_OLT_equipment_polling\|en]] \| [[FAQ._Опрос_оборудования_ZTE_OLT\|ru]]

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

Uscld2 в 14:03, 31 июля 2024

2024-07-31T14:03:54Z

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

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

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

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

Uscld2 в 06:50, 31 июля 2024

2024-07-31T06:50:21Z

← Предыдущая версия		Версия от 06:50, 31 июля 2024
Строка 38:		Строка 38:
	mib-compatibility iftable v2		mib-compatibility iftable v2
	</pre>		</pre>
	После выполнения этой команды снова прочитайте "Список интерфейсов" из карточки оборудования. Теперь индексы интерфейсов должны начинаться с 28..., как показано выше в примере.		После выполнения этой команды снова прочитайте "Список интерфейсов" из карточки оборудования. Теперь индексы интерфейсов должны начинаться с 28..., как показано выше в примере. Если получилось, теперь перейдите в Редактировать - Настройка интерфейсов/стекирования и нажмите "Сохранить" в списке интерфейсов. После этого убедитесь, что индексация в этой настройке изменилась на новую.

			Теперь нужно переинициализировать слоты GTGO и ETGO.

	~~==== Если не сработало ====~~
	В конфигурации вашего OLT вы найдете информацию о слотах наподобие этой:		В конфигурации вашего OLT вы найдете информацию о слотах наподобие этой:
	<pre>		<pre>
Строка 48:		Строка 49:
	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 командой:
			Удалите слоты GTGO и ETGO следующей командой с указанием номера слота:
	<pre>		<pre>
	del-card slotno 1		del-card slotno 1
	</pre>		</pre>
	Сохраните конфигурацию и перезагрузите OLT. При загрузке слоты будут переинициализированы.		Сохраните конфигурацию и перезагрузите OLT. При загрузке слоты будут переинициализированы и индексация PON интерфейсов теперь будет правильная.

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

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

Uscld2: /* Если не сработало */

2024-07-30T09:15:17Z

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

← Предыдущая версия		Версия от 09:15, 30 июля 2024
Строка 48:		Строка 48:
	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

Uscld2: /* Особенности шасси C300 */

2024-07-30T09:11:47Z

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

← Предыдущая версия		Версия от 09:11, 30 июля 2024
Строка 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>

	Однако есть определенный, довольно значимый процент оборудования 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 вы найдете информацию о слотах наподобие этой:		В конфигурации вашего OLT вы найдете информацию о слотах наподобие этой:
	<pre>		<pre>
Строка 35:		Строка 52:
	del-card slotno 1		del-card slotno 1
	</pre>		</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~~.

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

Uscld2: /* Особенности шасси C300 */

2024-03-05T07:41:02Z

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

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

	Вот пример индексов интерфейсов для C3xx FW 1.2.5 ~~(в первой версии счет полок начинается с 0)~~:		Вот пример индексов интерфейсов для C3xx FW 1.2.5:
	<pre>		<pre>
	.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.268435456 = STRING: "gpon_1/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.268435712 = STRING: "gpon_1/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.268435968 = STRING: "gpon_1/1/3"
	.1.3.6.1.2.1.31.1.1.1.1.268436224 = STRING: "~~gpon_0~~/1/4"		.1.3.6.1.2.1.31.1.1.1.1.268436224 = STRING: "gpon_1/1/4"
	</pre>		</pre>

	Вот пример индексов интерфейсов для C3xx FW 2.1.0 ~~(во второй версии счет полок начинается с 1)~~:		Вот пример индексов интерфейсов для C3xx FW 2.1.0:
	<pre>		<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.285278465 = STRING: "gpon_1/1/1"

Uscld2 в 08:11, 16 февраля 2024

2024-02-16T08:11:15Z

← Предыдущая версия		Версия от 08:11, 16 февраля 2024
Строка 1:		Строка 1:
			=== Настройка 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>

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

Uscld2 в 06:39, 31 января 2024

2024-01-31T06:39:05Z

← Предыдущая версия		Версия от 06:39, 31 января 2024
Строка 43:		Строка 43:
	</pre>		</pre>
	Такой же результат должен быть после обновления OLT с 1.2.5 на 2.1.0.		Такой же результат должен быть после обновления OLT с 1.2.5 на 2.1.0.

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

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

Uscld2 в 06:29, 25 января 2024

2024-01-25T06:29:23Z

← Предыдущая версия		Версия от 06:29, 25 января 2024
Строка 3:		Строка 3:
	Все что будет указано далее не имеет отношения к шасси серии C6xx (C600, C610). ZTE OLT на этом шасси известных проблем не имеет вовсе.		Все что будет указано далее не имеет отношения к шасси серии C6xx (C600, C610). ZTE OLT на этом шасси известных проблем не имеет вовсе.

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

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

Uscld2 в 06:28, 25 января 2024

2024-01-25T06:28:40Z

← Предыдущая версия		Версия от 06:28, 25 января 2024
Строка 1:		Строка 1:
	Оборудование ZTE OLT на шасси C220, C300, C320 имеет ряд известных проблем и еще больше пока еще неизвестных.		Оборудование ZTE OLT на шасси C220, C300, C320 имеет ряд известных проблем и еще больше пока еще неизвестных.

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

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