LibreNMS не находит оптических датчиков на GPON OLT ZTE ZXA10 C300/C320 и вообще никаких интерфейсов ONU
Я отвечаю за уровень доступа в небольшом провайдере и хочу, чтобы наши два GPON OLT отображались в мониторинге так же, как и всё остальное. Список пожеланий не экзотичный: температура шасси, загрузка CPU и RAM, счётчики по портам и то, что мне реально важно - оптическая сторона. То есть Rx/Tx в дБм для самих портов OLT и показатель Rx для каждого абонентского ONU.
- ZTE ZXA10 C300 и ZXA10 C320, SNMP v2c с community только для чтения
- LibreNMS 25.8.0-dev, самостоятельно размещённый поллер на той же площадке
- аплинки SFP и SFP+ на обоих OLT
Из коробки не получаю вообще ничего оптического:
# обнаружение завершается, устройство зелёное, но:
# - датчики мощности Rx/Tx трансивера не обнаружены ни для одного OLT
# - интерфейсов ONU в IF-MIB не существует, только собственные порты OLT
snmpwalk -v2c -c <community> <olt> IF-MIB::ifDescrЧто уже сделал:
- убедился, что сам SNMP здоров, графики трафика на аплинках и портах PON рисуются корректно
- переобнаруживал устройства после каждого изменения и проверял стандартные таблицы датчиков - все пустые
- искал готовый шаблон для семейства C320 и не нашёл ничего, что покрывало бы оптику порта GPON или ONU
Так в каком дереве эти устройства реально публикуют такие данные - и по собственным портам, и по каждому ONU - и удавалось ли кому-нибудь завести это в LibreNMS так, чтобы пережило обновление?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Коротко: ничего оптического на этих OLT нет в стандартном MIB, всё в приватном дереве ZTE 3902.
Начните с простого - температура шасси по .1.3.6.1.4.1.3902.1015.2.1.3.2. Есть гуляющее определение датчика PHP для неё с порогами 65/55/15/5 градусов. Не принимайте эти значения на веру, сверьте их с тем, при чём реально работает ваше шасси, прежде чем подключать к ним алертинг.
Сторона ONU - это уже реальная работа. IF-MIB описывает только интерфейсы OLT, а один порт PON может нести до 128 ONU, так что вешать интерфейс попросту не на что. В итоге люди строят индекс из полки, слота, порта и номера ONU, упакованных в одно целое число:
и используют его для дерева ONU:
В этом дереве есть уровни RX ONU и счётчики байт Counter64, так что трафик по каждому ONU получается из того же обхода.
Два предупреждения. Это набор пользовательских патчей, ничего не попало в апстрим, так что храните свои копии там, где сможете переприменить их после обновления. И OLT с более чем 300 ONU увеличивает число ваших датчиков примерно в десять раз, поллер это заметит. При таком масштабе кладите данные ONU в Components, а не в обычные интерфейсы.
Два вопроса, прежде чем кто-то напишет вам шаблон.
Обходили ли вы что-нибудь за пределами стандартных MIB? В семействе ZXA10 интересные данные не в IF-MIB, так что пустая таблица датчиков - ожидаемый результат, а не баг. Опубликуйте, что возвращает
Если это вернёт значение, дело в шляпе, а всё остальное - арифметика индексов.
Второй вопрос: сколько ONU на порт PON и сколько всего на шасси? Это число определяет, нужны ли вам обычные датчики или что-то полегче, и заметно меняет совет.
Так и оказалось. Ручной обход 3902 сразу вернул значения, и после подключения у меня теперь есть температура, CPU, память, пропускная способность, счётчики ошибок и RX в дБм и для портов OLT, и для ONU.
Предупреждение про масштаб тоже не было теоретическим. На C300 больше 300 ONU, и время работы поллера для этого устройства заметно выросло, как только каждый ONU превратился в датчики, так что данные по ONU переезжают в Components, а обычными датчиками остаётся только оптика OLT. Я бы всё же назвал это частичным решением, а не полным: работает, но это мой собственный набор патчей, и для C320 готового ничего нет.
Другой вендор, но тот же урок с моей стороны: если устройство всё же выдаёт цифры, сверьте их с дальним концом, прежде чем строить на них алертинг.
У нас было два линка по 20 км со сторонней (не Juniper) оптикой SFP+ между EX4550 и парой EX3300. Оба линка передавали трафик, но на EX4550
show interfaces diagnostics opticsпоказывалтогда как конец того же волокна на EX3300 сообщал 0,1196 мВт / -9,22 дБм. Это дефект масштабирования в Junos на EX4550, PR1007055, исправлен в 12.3R8. Пока не обновились, значение с EX4550 считали декоративным и использовали дальний конец.
Из вторых рук, так что относитесь с осторожностью: на ICX 7450 и ICX 7550 оптический мониторинг якобы остаётся пустым для партномеров Ruckus 33211-100 и 33210-100, тогда как эквиваленты с кодировкой Brocade в том же шасси отчитываются нормально; отслеживается как FI-264785, фикс ожидается примерно в сборке 08.0.95j. Стоит сделать
show optic, прежде чем кто-то начнёт переустанавливать модули.