LibreNMS não encontra sensores ópticos nas OLTs ZTE ZXA10 C300/C320 e nenhuma interface de ONU
Eu cuido da camada de acesso em um ISP pequeno e quero que nossas duas OLTs GPON apareçam no monitoramento do mesmo jeito que tudo o mais aparece. A lista de desejos não é nada exótico: temperatura do chassi, carga de CPU e RAM, contadores por porta e a parte que eu realmente me importo, o lado óptico. Ou seja, Rx/Tx em dBm das próprias portas da OLT e um valor de Rx por ONU assinante.
- ZTE ZXA10 C300 e ZXA10 C320, community SNMP v2c somente leitura
- LibreNMS 25.8.0-dev, poller self-hosted no mesmo site
- uplinks SFP e SFP+ nas duas OLTs
De fábrica não vem nada óptico:
# discovery completes, device is green, but:
# - no transceiver Rx/Tx power sensors are discovered for either OLT
# - ONU interfaces do not exist in IF-MIB, only the OLT's own ports
snmpwalk -v2c -c <community> <olt> IF-MIB::ifDescrO que eu já fiz:
- confirmei que o próprio SNMP está saudável, os gráficos de tráfego nos uplinks e nas portas PON são desenhados corretamente
- redescobri os dispositivos depois de cada mudança e conferi as tabelas de sensores padrão, todas vazias
- procurei um template pronto para a família C320 e não achei nada cobrindo porta GPON ou óptica de ONU
Então em qual árvore essas caixas realmente publicam isso, tanto para as próprias portas quanto por ONU, e alguém já conseguiu colocar isso no LibreNMS de um jeito que sobrevive a uma atualizaçã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
Resumindo: nada óptico nessas OLTs vive em MIB padrão, está tudo na árvore enterprise privada da ZTE, a 3902.
Comece pela mais fácil, a temperatura do chassi em .1.3.6.1.4.1.3902.1015.2.1.3.2. Tem uma definição de sensor em PHP circulando por aí com limites de 65/55/15/5 graus. Não confie de olhos fechados nesses valores, confira contra o que o seu chassi realmente roda antes de ligar alertas a eles.
O lado da ONU é o trabalho de verdade. A IF-MIB só descreve as interfaces da OLT, e uma única porta PON pode carregar até 128 ONUs, então não tem em que pendurar uma interface. O que o pessoal acabou fazendo foi montar o índice a partir de shelf, slot, porta e número da ONU compactados em um único inteiro:
e usando isso contra a árvore de ONU:
Essa árvore traz os níveis de RX da ONU e contadores de bytes Counter64, então o tráfego por ONU sai do mesmo walk.
Dois avisos. Isso é uma pilha de patches de usuário, nada que chegou ao upstream, então guarde suas cópias em algum lugar onde dê para reaplicar depois de uma atualização. E uma OLT com mais de 300 ONUs multiplica sua contagem de sensores por uns dez, e o poller vai sentir isso. Nessa escala, coloque os dados de ONU em Components em vez de em interfaces comuns.
Duas perguntas antes que alguém escreva um template para você.
Você chegou a fazer walk em algo fora das MIBs padrão? Na família ZXA10 os dados interessantes não estão na IF-MIB, então uma tabela de sensores vazia é o resultado esperado, não um bug. Poste o que você recebe de volta de
Se isso retornar um valor, você já está no caminho certo e o resto é aritmética de índice.
Segundo: quantas ONUs por porta PON, e quantas por chassi no total? Esse número decide se você quer sensores comuns ou algo mais leve, e muda bastante o conselho.
Foi isso mesmo. Fazer walk manual na 3902 retornou valores na hora, e depois de configurar tudo agora tenho temperatura, CPU, memória, banda, contadores de erro e RX em dBm tanto das portas da OLT quanto das ONUs.
O aviso sobre escala também não era teórico. A C300 carrega bem mais de 300 ONUs, e o tempo de execução do poller para esse dispositivo ficou visivelmente mais longo assim que cada ONU virou um monte de sensores, então os dados por ONU estão migrando para Components e só a óptica da OLT continua como sensor normal. Eu ainda chamaria isso de parcial, não de resolvido: funciona, mas é o meu próprio conjunto de patches, e não existe nada pronto para a C320.
Fabricante diferente, mesma lição do meu lado: quando a caixa te dá números, confira contra a outra ponta antes de montar alertas em cima disso.
Tínhamos dois links de 20 km com SFP+ não Juniper entre um EX4550 e um par de EX3300. Os dois links passavam tráfego, mas no EX4550 o
show interfaces diagnostics opticsimprimiaenquanto a ponta EX3300 da mesma fibra reportava 0,1196 mW / -9,22 dBm. Isso é um defeito de escala do Junos no EX4550, PR1007055, corrigido no 12.3R8. Até atualizarmos, tratávamos a leitura do EX4550 como decoração e usávamos a outra ponta.
De segunda mão, então leve com cautela: no ICX 7450 e no ICX 7550 o monitoramento óptico aparentemente fica em branco para os part numbers fornecidos pela Ruckus 33211-100 e 33210-100, enquanto equivalentes codificados como Brocade no mesmo chassi reportam normalmente, rastreado como FI-264785, com correção esperada por volta de um build 08.0.95j. Vale rodar um
show opticantes de sair reencaixando módulo.