OLTs ZXA10 en LibreNMS: sin dBm de transceptor en las páginas de puerto, y los sensores de ventilador y fuente desaparecieron
Sondeamos una flota mixta de OLT ZTE ZXA10 desde LibreNMS y hay dos cosas mal. Sospecho que no están relacionadas, pero no estoy seguro.
- ZTE ZXA10 C300 en V2.1.0, todavía en servicio en un POP antiguo
- ZTE ZXA10 C620 en V2.0.30, más un C650 y un C650E
- un ZTE ZXA10 C320 que solía comportarse bien
- enlaces ascendentes SFP y SFP+, tarjetas GPON debajo de ellos
Primer problema: las páginas de puerto no tienen sensores de transceptor en absoluto. Nada de potencia de recepción o transmisión en dBm, ni temperatura del módulo, ni voltaje de alimentación, ni corriente de polarización del láser. Esos son los números que quiero para detectar un conector sucio antes de que los suscriptores empiecen a llamar.
Segundo problema: los sensores de estado que sí funcionaban en el C320, ventiladores, fuentes de alimentación y estado de tarjeta, desaparecieron silenciosamente tras un redescubrimiento. Ningún error en el log, nada falló, simplemente ya no están en el dispositivo.
Recorriendo las cajas a mano, los datos ópticos claramente están en el MIB en algún sitio, pero un OID que responde en una plataforma no devuelve nada en otra:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Probado hasta ahora:
- redescubrimiento y sondeo completo en cada dispositivo
- comparar lo que responde un C650 frente a lo que responde el C300 en el mismo OID
- comprobar si las jaulas vacías son la razón por la que el descubrimiento se rinde
¿Dónde viven realmente las lecturas ópticas en la familia ZXA10, y qué hace que un sensor de estado desaparezca en el descubrimiento sin registrar nada?
Comments 5
Ambos son conocidos, y como sospechabas no están relacionados.
Qué tabla óptica obtienes depende de la plataforma, y las dos nunca coexisten en una misma caja. El C300 más antiguo, probado aquí contra V2.1.0, expone zxAnOpticalModuleMonTable:
C620 en V2.0.30, C650 y C650E exponen en su lugar zxAnOpticalModuleInfoTable:
Cualquiera de las dos tablas te entrega las mismas cuatro lecturas: potencia rx y tx en dBm, temperatura del módulo, voltaje de alimentación, corriente de polarización del láser. Los valores en bruto necesitan el escalado de 0.001. Dos centinelas también necesitan filtrarse, o cada jaula vacía del chasis te dará alarma: un puerto no soportado o una jaula sin poblar responde 2147483647, y un puerto apagado responde -80000. La presencia de la tarjeta no pertenece en absoluto al sondeo óptico, eso es un sensor de estado operativo separado que se salta las ranuras sin poblar.
Tus ventiladores, fuentes y estado de tarjeta desaparecidos son un bug distinto. Las entradas de estado en el YAML de la plataforma les faltaba la clave value:, y sin ella el descubrimiento termina leyendo el nombre de la tabla como si fuera una columna, no encuentra nada usable y descarta el sensor silenciosamente, sin error en ningún sitio, por lo que solo lo notaste como una ausencia. Devolver la clave restauró seis sensores en el equipo de prueba C320 de aquí.
Aviso justo antes de que planifiques en torno a esto: esto va montado en un cambio que sigue abierto en vez de fusionado, y la revisión ya recortó de él el monitoreo de errores de ethernet por considerarlo fuera de alcance. Trátalo como un parche que llevas tú, no como un arreglo que esperar.
Muéstranos el sysDescr que reporta cada una de esas cajas. C300, C320, C620, C650 y C650E no son una sola familia en lo que respecta al MIB óptico, así que un OID que responde en algunos de ellos y se queda callado en el resto es lo esperado, no un fallo.
Publica el final de un walk de los dos que más difieren, el C300 y uno de los C650, en el OID que ya probaste. Si uno responde y el otro está vacío, esa es toda la historia y el arreglo es por plataforma.
Además mantén tus dos problemas separados. Los sensores de ventilador y fuente que faltan son un problema de definición de descubrimiento y no tienen nada que ver con qué tabla óptica implementa el OLT.
Confirmando la brecha desde el otro lado. Pregunté sobre esta misma familia en 25.8.0-dev: un OLT GPON C320, y lo que buscaba era graficar en los puertos GPON en ambos extremos, en el OLT y en las ONU - niveles de potencia rx y tx, cuánto mide cada enlace, utilización por puerto - además de si ya existía una plantilla para la familia en algún sitio.
Se cerró sin que nadie publicara OID, un walk o un método, así que todo lo que documenta es que la cobertura de fábrica para la familia C320 es parcial. En retrospectiva debería haber adjuntado un walk a la solicitud. Si de todos modos estás construyendo esto, los niveles ópticos de las ONU son la parte que nadie ha hecho y muchos de nosotros la usaríamos.
Eso coincide con lo que hace la flota. El C300 responde en .1.3.6.1.4.1.3902.1015.3.1.13.1 y no devuelve nada en el otro OID, el C620 y el C650 son al revés, y el C650E se comporta como el C650.
Los valores vuelven como enteros que necesitan el escalado de 0.001, exactamente como se describió. Los que al principio parecían basura ahora tienen sentido: 2147483647 en las jaulas que nunca poblamos, y -80000 en dos puertos donde el extremo remoto está apagado. Ambos centinelas son reales aquí, así que cualquiera que escriba umbrales contra los números en bruto tendrá una lista de alertas muy ruidosa.
Revisé también el YAML de la plataforma y aquí también falta la clave value:. Lo mantendremos localmente ya que el cambio sigue abierto. Separar los dos problemas fue la parte que tenía mal desde el principio.
Una cosa a tener en cuenta mientras construyes esto: los datos DOM son un subconjunto en todas partes, no solo en ZTE.
En SONiC un CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 tiene su EEPROM leído sin problemas, y TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR más TRANSCEIVER_STATUS se rellenan todos con identidad más temperatura, voltaje, polarización y potencia por carril, pero el grupo de control y estado simplemente está ausente: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode y get_power_override no devuelven nada en la vista de base de datos, así que si necesitas esos bits tienes que pedírselos tú mismo a la API de la plataforma.
Misma lección desde el lado del firewall. En PAN-OS, show transceiver-detail all imprime el bloque de diagnóstico, y el primer campo que hay que leer es diagnostic-monitor. Si dice No, el módulo no implementa monitoreo óptico digital y todos los valores vuelven como N/A. Ahí no hay nada roto, simplemente no hay nada que leer. Vale la pena codificar esa distinción en tu alertado para que un módulo sin DOM no se vea igual que un puerto muerto.