OLT ZXA10 в LibreNMS: нет dBm трансивера на страницах портов, и пропали датчики вентиляторов и блока питания
Опрашиваем смешанный парк OLT ZTE ZXA10 из LibreNMS, и здесь неправильно две вещи. Подозреваю, что они не связаны, но не уверен.
- ZTE ZXA10 C300 на V2.1.0, всё ещё в эксплуатации на старом POP
- ZTE ZXA10 C620 на V2.0.30, плюс C650 и C650E
- один ZTE ZXA10 C320, который раньше вёл себя нормально
- аплинки SFP и SFP+, ниже платы GPON
Первая проблема: на страницах портов вообще нет датчиков трансивера. Ни мощности приёма или передачи в дБм, ни температуры модуля, ни напряжения питания, ни тока смещения лазера. Это именно те цифры, которые мне нужны, чтобы ловить грязный коннектор до того, как начнут звонить абоненты.
Вторая проблема: датчики состояния, которые работали на C320 - вентиляторы, блоки питания и состояние платы - тихо исчезли после повторного обнаружения. В логе никакой ошибки, ничего не упало, их просто больше нет на устройстве.
При ручном обходе коробок оптические данные явно где-то есть в MIB, но OID, который отвечает на одной платформе, ничего не возвращает на другой:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Что уже пробовал:
- повторное обнаружение и полный опрос на каждом устройстве
- сравнение того, что отвечает C650, с тем, что отвечает C300, на одном и том же OID
- проверка, не сдаётся ли обнаружение из-за пустых слотов
Где на самом деле живут оптические показания в семействе ZXA10, и что заставляет датчик состояния исчезать при обнаружении, ничего не логируя?
Comments 5
Обе проблемы известны, и, как вы догадались, они не связаны.
Какую таблицу оптики вы получаете, зависит от платформы, и они никогда не сосуществуют на одной коробке. Старый C300, здесь протестирован на V2.1.0, отдаёт zxAnOpticalModuleMonTable:
C620 на V2.0.30, C650 и C650E вместо этого отдают zxAnOpticalModuleInfoTable:
Любая из таблиц отдаёт одни и те же четыре показания: мощность rx и tx в дБм, температура модуля, напряжение питания, ток смещения лазера. Сырые значения нужно масштабировать на 0.001. Также нужно фильтровать два значения-маркера, иначе каждый пустой слот в шасси будет вам аварийно сигналить: неподдерживаемый или незаполненный слот отвечает 2147483647, а тёмный порт отвечает -80000. Присутствие платы вообще не относится к опросу оптики, это отдельный датчик операционного статуса, который пропускает незаполненные слоты.
Ваши пропавшие вентиляторы, блоки питания и состояние плат - это другой баг. В записях состояния в YAML платформы отсутствовал ключ value:, и без него обнаружение в итоге читает имя таблицы так, будто это столбец, ничего полезного не находит и молча отбрасывает датчик, без единой ошибки где-либо, поэтому вы заметили это только как отсутствие. Возврат ключа на место восстановил шесть датчиков на тестовом стенде с C320 здесь.
Честное предупреждение, прежде чем на это рассчитывать: это едет в изменении, которое ещё открыто, а не влито, и при ревью из него уже вырезали мониторинг ethernet-ошибок как выходящий за рамки. Относитесь к этому как к патчу, который вы носите сами, а не как к исправлению, которого стоит ждать.
Покажите нам sysDescr, который отдаёт каждая из этих коробок. C300, C320, C620, C650 и C650E - не одно семейство с точки зрения оптического MIB, так что OID, отвечающий на одних и молчащий на остальных, - это ожидаемо, а не неисправность.
Выложите хвост обхода с двух самых разных - C300 и одного из C650 - по OID, который вы уже пробовали. Если один отвечает, а другой пуст - это и есть вся история, и исправление специфично для платформы.
Также держите ваши две проблемы раздельно. Пропавшие датчики вентиляторов и блока питания - это проблема определения обнаружения и не имеет отношения к тому, какую таблицу оптики реализует OLT.
Подтверждаю пробел с другой стороны. Я спрашивал про то же семейство на 25.8.0-dev: GPON OLT C320, и мне нужны были графики на портах GPON с обеих сторон, на OLT и на ONU - уровни мощности rx и tx, на сколько измеряется каждый линк, утилизация по порту - плюс существует ли уже где-то шаблон для этого семейства.
Вопрос закрыли, так и не получив ни OID, ни обхода, ни метода, так что это документирует только то, что покрытие "из коробки" для семейства C320 частичное. Задним числом стоило приложить обход к запросу. Если вы всё равно это строите - оптические уровни ONU это то, чего никто ещё не сделал, и многие из нас бы это использовали.
Совпадает с тем, что происходит у нас в парке. C300 отвечает на .1.3.6.1.4.1.3902.1015.3.1.13.1 и ничего не возвращает на другом OID, C620 и C650 наоборот, а C650E ведёт себя как C650.
Значения возвращаются как целые числа, нуждающиеся в масштабировании на 0.001, точно как описано. То, что сначала выглядело мусором, теперь имеет смысл: 2147483647 на слотах, которые мы никогда не заполняли, и -80000 на двух портах, где дальний конец выключен. Оба маркера у нас реальны, так что любой, кто пишет пороги по сырым числам, получит очень шумный список алертов.
Также проверили YAML платформы, и ключ value: у нас тоже отсутствует. Будем держать это локально, пока изменение открыто. Разделение двух проблем - это то, что я изначально сделал неправильно.
Одну вещь стоит держать в голове, пока это строите: данные DOM везде подмножество, не только у ZTE.
В SONiC EEPROM CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 читается без проблем, и TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR плюс TRANSCEIVER_STATUS заполняются идентификацией плюс температурой, напряжением, смещением и мощностью по каждой линии, но группа управления и статуса просто отсутствует: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode и get_power_override ничего не возвращают в представлении базы данных, так что если вам нужны эти биты - идите спрашивать сам API платформы напрямую.
Тот же урок со стороны файрвола. На PAN-OS show transceiver-detail all печатает диагностический блок, и первое поле, которое стоит прочитать - diagnostic-monitor. Если там No, модуль не реализует цифровой оптический мониторинг, и каждое значение возвращается как N/A. Там ничего не сломано, там просто нечего читать. Стоит заложить это различие в алертинг, чтобы модуль без DOM не выглядел так же, как мёртвый порт.