NAPALM get_optics на nxos_ssh возвращает DOM только по линии 1 для модулей QSFP-100G-CWDM4
Подключаю телеметрию оптики по каждому порту в мониторинг для пары фабрик Nexus 9000. Сбор идёт через NAPALM, и геттер, на который опираюсь, это get_optics().
- пары leaf и spine Nexus 9000
- модули QSFP-100G-CWDM4 на линках фабрики
- NAPALM с драйвером nxos_ssh, транспорт SSH, NX-API пока не включён
На четырёхлинейном модуле 100G геттер возвращает ровно один канал:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}У самого коммутатора данные явно есть - show interface transceiver details выводит мощность Rx, мощность Tx и ток смещения лазера по всем четырём линиям - так что похоже на парсер, а не на платформу.
Что я проверил:
- одинаковый результат на каждом порту QSFP-100G-CWDM4, который опрашиваю, так что это не один странный модуль
- порты SFP+ возвращаются корректно, что логично, когда линия всего одна
- прошёлся по коду разбора оптики в драйвере, и похоже, что подхватывается только самый первый блок DOM
Собирает ли кто-нибудь реально DOM по линиям через NAPALM на NX-OS, или все в итоге сами парсят вывод коммутатора?
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
Какая именно версия NAPALM и на какой ветке NX-OS эти leaf? Код оптики в nxos_ssh переписывался не один раз, а вывод по трансиверу на коммутаторе тоже отформатирован не идентично между ветками, так что важны обе половины, прежде чем называть это багом.
Одна вещь, которую стоит сделать, прежде чем писать собственный парсер: вызовите get_optics() на одном из портов SFP+ и положите эту структуру рядом со структурой CWDM4. Если обе возвращаются с одинаковым скелетом, и различаются только значения, драйвер нормально проходит по тексту и просто останавливается после первого совпавшего блока. Если формы разные, он вообще никогда не доходит до посегментной части на портах QSFP. Это два разных исправления, и вывод SFP+ - самый дешёвый способ их различить.
Текущий релиз с PyPI на обоих коллекторах, а leaf и spine сидят на одной ветке NX-OS, так что получаю одно и то же, куда бы ни направил - не одна странная коробка.
Сделал запрошенное сравнение с SFP+. Одинаковый скелет в обоих случаях: physical_channels.channel с единственным элементом по индексу 0, все три значения заполнены. Правильный ответ для одноканального модуля, неправильный для CWDM4. То есть парсер не проваливается в поиске посегментной части вывода, он находит блок, заполняет его и на этом останавливается. Именно так выглядел код, когда я его прочитал, просто хотел, чтобы кто-то подтвердил, что я его не неправильно понял.
Это пробел в драйвере, а не что-то с вашей стороны. Есть открытый pull request к nxos_ssh, переписывающий разбор оптики: каждая линия возвращается как собственный элемент под physical_channels.channel вместо остановки прохода на индексе 0, и каждый элемент несёт собственный уровень Rx, уровень Tx и ток смещения лазера. Фикстуры, поставляемые с ним, построены на четырёхлинейном QSFP-100G-CWDM4, так что он написан именно под ваш модуль. Я запускал его только на лабораторной коробке, так что воспринимайте это как то, что стоит попробовать, а не как рекомендацию для продакшен-коллектора.
Пока это не попадёт в релиз, который можно установить, прагматичный путь - пропустить геттер для портов 100G и парсить
show interface transceiver detailsсамостоятельно, а затем отправлять каждую линию в мониторинг как отдельный ряд. Немного больше кода на поддержке, зато перестаёте выбрасывать три четверти сигнала.Каким бы путём ни пошли, оповещайте по каждой линии. Одна деградировавшая линия на CWDM4 утянет вниз весь линк, никогда не проявившись, если вы смотрите только на линию 1.
Видимость по линиям на Nexus важнее, чем ожидается.
Мы наткнулись на дефект Cloud Scale на Nexus 9000 с QSFP-100G-SR4-S, разбитым на 4x25G. Нужен был только один из четырёх портов 25G, остальные три оставались выключены, и тот, что был нужен, так и не поднимался. Что нас вытащило - сначала поднять всю группу целиком:
no shutdownна каждом из четырёх подинтерфейсов, дать линии 1 устояться, затем снова выключить три запасных. Держите FEC одинаковым по всей группе, пока вы там - странная настройка на одной линии не остаётся вежливо только на ней.Суть в том, что имея в дашбордах только линию 1, вы слепы к большей части того, что делает порт 100G. Дополнительный разбор стоит того, чтобы взять на себя.