OLTs ZXA10 no LibreNMS: sem dBm de transceptor nas páginas de porta, e sumiram os sensores de fan e PSU
Fazemos polling de uma frota mista de OLTs ZTE ZXA10 pelo LibreNMS e duas coisas estão erradas. Suspeito que não têm relação uma com a outra, mas não tenho certeza.
- ZTE ZXA10 C300 na V2.1.0, ainda em serviço num POP antigo
- ZTE ZXA10 C620 na V2.0.30, mais um C650 e um C650E
- um ZTE ZXA10 C320 que costumava se comportar
- uplinks SFP e SFP+, placas GPON abaixo deles
Primeiro problema: as páginas de porta não têm sensor de transceptor nenhum. Sem potência de recepção ou transmissão em dBm, sem temperatura do módulo, sem tensão de alimentação, sem corrente de bias do laser. São esses os números que eu quero para pegar um conector sujo antes dos assinantes começarem a ligar.
Segundo problema: os sensores de estado que funcionavam no C320, fans, fontes e estado da placa, sumiram silenciosamente depois de uma redescoberta. Nenhum erro no log, nada falhou, eles simplesmente não estão mais no dispositivo.
Percorrendo as caixas na mão, os dados ópticos claramente estão em algum lugar da MIB, mas um OID que responde numa plataforma não retorna nada em outra:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Já tentei:
- redescoberta e um poll completo em cada dispositivo
- comparar o que um C650 responde contra o que o C300 responde no mesmo OID
- checar se gaiolas vazias são o motivo da descoberta desistir
Onde as leituras ópticas realmente moram na família ZXA10, e o que faz um sensor de estado desaparecer na descoberta sem logar nada?
Comments 5
As duas são conhecidas, e como você imaginou não têm relação uma com a outra.
Qual tabela óptica você recebe depende da plataforma, e as duas nunca coexistem numa mesma caixa. O C300 mais antigo, testado aqui contra a V2.1.0, expõe zxAnOpticalModuleMonTable:
C620 na V2.0.30, C650 e C650E expõem zxAnOpticalModuleInfoTable em vez disso:
Qualquer uma das tabelas entrega as mesmas quatro leituras: potência rx e tx em dBm, temperatura do módulo, tensão de alimentação, corrente de bias do laser. Os valores brutos precisam do fator de escala 0,001. Duas sentinelas também precisam de filtro, ou toda gaiola vazia do chassi vai te alarmar: uma porta não suportada ou uma gaiola não populada responde 2147483647, e uma porta apagada responde -80000. Presença de placa não entra no polling óptico de jeito nenhum, isso é um sensor de estado operacional separado, que pula slots não populados.
Seus fans, PSUs e estado de placa sumidos são um bug diferente. As entradas de estado no YAML da plataforma estavam sem a chave value:, e sem ela a descoberta acaba lendo o nome da tabela como se fosse uma coluna, não acha nada utilizável e derruba o sensor silenciosamente, sem erro em lugar nenhum, e é por isso que você só notou como uma ausência. Devolver a chave restaurou seis sensores na bancada de teste do C320 aqui.
Um aviso justo antes de você planejar em cima disso: isso está numa mudança ainda aberta, não mesclada, e a revisão já cortou o monitoramento de erro de ethernet dela como fora de escopo. Trate como um patch que você carrega, não uma correção para esperar.
Mostra para a gente o sysDescr que cada uma dessas caixas reporta. C300, C320, C620, C650 e C650E não são uma família só no que diz respeito à MIB óptica, então um OID que responde em algumas delas e fica mudo no resto é esperado, não é falha.
Poste o final de um walk das duas que mais diferem, o C300 e um dos C650, no OID que você já tentou. Se uma responde e a outra fica vazia, essa é a história toda e a correção é por plataforma.
Também mantenha seus dois problemas separados. Os sensores de fan e PSU faltando são uma questão de definição de descoberta e não têm nada a ver com qual tabela óptica a OLT implementa.
Confirmando a lacuna do outro lado. Perguntei sobre essa mesma família na 25.8.0-dev: uma OLT GPON C320, e o que eu queria era gráfico nas portas GPON nas duas pontas, na OLT e nas ONUs - níveis de potência rx e tx, quanto cada link mede de distância, utilização por porta - além de saber se já existia um template para a família em algum lugar.
Foi fechado sem ninguém postar OIDs, um walk ou um método, então tudo que documenta é que a cobertura pronta para a família C320 é parcial. Em retrospecto eu deveria ter anexado um walk ao pedido. Se você está construindo isso de qualquer forma, níveis ópticos de ONU é a parte que ninguém fez e muita gente aqui usaria.
Isso bate com o que a frota faz. O C300 responde em .1.3.6.1.4.1.3902.1015.3.1.13.1 e não retorna nada no outro OID, o C620 e o C650 são o contrário, e o C650E se comporta como o C650.
Os valores voltam como inteiros precisando do fator de escala 0,001, exatamente como descrito. Os que pareciam lixo no começo fazem sentido agora: 2147483647 nas gaiolas que nunca populamos, e -80000 em duas portas onde a outra ponta está desligada. As duas sentinelas são reais aqui, então quem escrever thresholds em cima dos números brutos vai ter uma lista de alertas bem barulhenta.
Chequei o YAML da plataforma também e a chave value: está faltando do nosso lado também. Vou carregar isso localmente já que a mudança ainda está aberta. Separar os dois problemas foi a parte que eu tinha errado desde o início.
Uma coisa para ter em mente enquanto você constrói isso: dados de DOM são um subconjunto em todo lugar, não só na ZTE.
No SONiC, um QSFP28 CISCO-AVAGO AFBR-89CDDZ-CS3 tem a EEPROM lida sem problema, e TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR mais TRANSCEIVER_STATUS todos preenchem com identidade mais temperatura, tensão, bias e potência por lane, mas o grupo de controle e status está simplesmente ausente: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode e get_power_override não retornam nada na visão do banco de dados, então se você precisa desses bits vai ter que pedir para a API da plataforma diretamente.
Mesma lição do lado do firewall. No PAN-OS, show transceiver-detail all imprime o bloco de diagnóstico, e o primeiro campo a ler é diagnostic-monitor. Se disser No, o módulo não implementa monitoramento óptico digital e todo valor volta N/A. Nada está quebrado ali, só não tem nada para ler. Vale codificar essa distinção no seu alerting para um módulo sem DOM não parecer a mesma coisa que uma porta morta.