NAPALM get_optics no nxos_ssh retorna só o DOM da lane 1 para módulos QSFP-100G-CWDM4
Estou plugando telemetria óptica por porta no monitoramento de alguns fabrics Nexus 9000. A coleta passa pelo NAPALM, e o getter que uso é o get_optics().
- pares leaf e spine Nexus 9000
- módulos QSFP-100G-CWDM4 nos links do fabric
- NAPALM com o driver nxos_ssh, transporte SSH, NX-API ainda não habilitado
Em um módulo de 100G de quatro lanes o getter devolve exatamente um canal:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}O switch claramente tem os dados - o show interface transceiver details imprime Rx power, Tx power e bias current das quatro lanes - então isso parece coisa do parser, não da plataforma.
O que já conferi:
- mesmo resultado em toda porta QSFP-100G-CWDM4 que consulto, então não é um módulo isolado
- as portas SFP+ voltam corretas, o que faz sentido quando só existe uma lane para reportar
- li o parsing de óptica do driver e parece que só o primeiro bloco de DOM é pego
Alguém está de fato coletando DOM por lane via NAPALM no NX-OS, ou todo mundo acaba fazendo scraping da saída do switch na mão?
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
Qual versão exata do NAPALM, e em que trem de NX-OS estão essas leaves? O código de óptica no nxos_ssh já foi reescrito mais de uma vez, e a saída de transceiver no switch também não é formatada de forma idêntica entre trens, então as duas metades importam antes de alguém chamar isso de bug.
Uma coisa que vale a pena fazer antes de sair escrevendo seu próprio parser: chame get_optics() em uma das portas SFP+ e coloque essa estrutura ao lado da do CWDM4. Se as duas voltarem com o mesmo esqueleto e só os valores diferirem, o driver está percorrendo o texto direitinho e simplesmente desiste depois do primeiro bloco que casa. Se tiverem formatos diferentes, ele nunca chega na seção por lane nas portas QSFP. São dois consertos diferentes, e a saída da SFP+ é o jeito mais barato de diferenciar os dois.
Versão atual direto do PyPI nos dois coletores, e as leaves e as spines estão no mesmo trem de NX-OS, então recebo a mesma coisa de volta em qualquer lugar que eu aponte - não é uma caixa isolada.
Fiz a comparação com SFP+ que você pediu. Mesmo esqueleto nos dois casos: physical_channels.channel com um único elemento no índice 0, os três valores preenchidos. Resposta certa para um módulo de uma lane, resposta errada para CWDM4. Então o parser não está falhando em achar a parte por lane da saída, ele casa um bloco, preenche e para por aí. Que foi a cara que o código teve quando eu li, eu só queria que alguém confirmasse que eu não estava lendo errado.
Isso é uma lacuna no driver, não algo do seu lado. Existe um pull request aberto contra o nxos_ssh que reescreve o parsing de óptica: cada lane volta como seu próprio elemento sob physical_channels.channel em vez da varredura parar no índice 0, e cada elemento traz seu próprio Rx level, Tx level e laser bias current. As fixtures que acompanham ele são construídas em cima de um QSFP-100G-CWDM4 de quatro lanes, então foi escrito contra o seu módulo exato. Eu só rodei em uma caixa de laboratório, então trate como algo para experimentar e não como recomendação para um coletor de produção.
Até isso cair em uma release que você possa instalar, o caminho pragmático é pular o getter para as portas de 100G e fazer o parsing do
show interface transceiver detailsvocê mesmo, depois empurrar cada lane para o monitoramento como sua própria série. Um pouco mais de código para manter, mas você para de jogar fora três quartos do sinal.Seja qual caminho você escolher, alerte por lane. Uma lane degradada em um CWDM4 vai arrastar o link inteiro sem nunca aparecer se a lane 1 é tudo que você observa.
Visibilidade por lane importa mais em Nexus do que as pessoas esperam.
Esbarramos em um defeito de Cloud Scale em um Nexus 9000 com um QSFP-100G-SR4-S dividido em 4x25G. Só uma das quatro portas de 25G era desejada, as outras três ficaram fechadas, e a que importava nunca linkou. O que nos tirou dessa foi subir o grupo inteiro primeiro -
no shutdownem cada uma das quatro sub-interfaces - deixar a lane 1 assentar, depois fechar as três sobressalentes de novo. Mantenha o FEC idêntico no grupo inteiro enquanto estiver nisso também; uma configuração estranha em uma única lane não fica educadamente restrita àquela lane.O ponto é, com só a lane 1 nos seus dashboards você está cego para a maior parte do que uma porta de 100G está fazendo. O parsing extra vale a pena manter.