LibreNMS no encuentra sensores ópticos en OLTs ZTE ZXA10 C300/C320 ni ninguna interfaz de ONU
Llevo la capa de acceso de un ISP pequeño y quiero que nuestras dos OLT GPON aparezcan en la monitorización igual que todo lo demás. La lista de deseos no es exótica: cuánto calienta el chasis, carga de CPU y RAM, contadores por puerto, y la parte que de verdad me importa, el lado óptico. Eso significa Rx/Tx en dBm para los propios puertos de la OLT y una cifra de Rx por ONU abonado.
- ZTE ZXA10 C300 y ZXA10 C320, comunidad SNMP v2c de solo lectura
- LibreNMS 25.8.0-dev, poller autohospedado en el mismo sitio
- Uplinks SFP y SFP+ en ambas OLT
De fábrica no obtengo nada óptico en absoluto:
# el discovery se completa, el equipo está en verde, pero:
# - no se descubre ningún sensor de potencia Rx/Tx de transceptor para ninguna OLT
# - las interfaces de ONU no existen en IF-MIB, solo los propios puertos de la OLT
snmpwalk -v2c -c <community> <olt> IF-MIB::ifDescrLo que ya he hecho:
- verifiqué que el propio SNMP está sano, las gráficas de tráfico en los uplinks y los puertos PON se dibujan correctamente
- volví a hacer discovery de los equipos tras cada cambio y comprobé las tablas de sensores estándar, todas vacías
- busqué una plantilla lista para la familia C320 y no encontré ninguna que cubra la óptica del puerto GPON ni de las ONU
Así que ¿en qué árbol publican estos equipos realmente eso, tanto para sus propios puertos como por ONU, y alguien ha conseguido meterlo en LibreNMS de una forma que sobreviva a una actualización?
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
Versión corta: nada óptico en estas OLT vive en un MIB estándar, todo está en el árbol privado de empresa de ZTE 3902.
Empieza por lo fácil, la temperatura del chasis en .1.3.6.1.4.1.3902.1015.2.1.3.2. Hay una definición de sensor PHP circulando por ahí con umbrales de 65/55/15/5 grados. No te los creas a ciegas, compáralos con lo que realmente marca tu chasis antes de conectarles alertas.
El lado de las ONU es el trabajo de verdad. IF-MIB solo describe las interfaces de la OLT, y un solo puerto PON puede llevar hasta 128 ONU, así que no hay nada de dónde colgar una interfaz. Lo que la gente terminó haciendo fue construir el índice a partir de shelf, slot, puerto y número de ONU empaquetados en un solo entero:
y usarlo contra el árbol de ONU:
Ese árbol lleva los niveles RX de las ONU y contadores Counter64 de bytes, así que el tráfico por ONU sale del mismo walk.
Dos advertencias. Esto es un montón de parches de usuarios, nada que haya llegado al upstream, así que guarda tus copias en algún sitio donde puedas volver a aplicarlas tras una actualización. Y una OLT con más de 300 ONU multiplica tu número de sensores por unas diez veces, cosa que el poller va a notar. A esa escala, mete los datos de ONU en Components en lugar de en interfaces normales.
Dos preguntas antes de que nadie te escriba una plantilla.
¿Hiciste algún walk fuera de los MIB estándar? En la familia ZXA10 los datos interesantes no están en IF-MIB, así que una tabla de sensores vacía es el resultado esperado, no un bug. Publica lo que te devuelve
Si eso devuelve un valor, vas por buen camino y el resto es aritmética de índices.
Segundo: ¿cuántas ONU por puerto PON, y cuántas por chasis en total? Ese número decide si quieres sensores normales o algo más ligero, y cambia bastante el consejo.
Eso era. Hacer el walk de 3902 a mano devolvió valores de inmediato, y tras conectarlo ahora tengo temperatura, CPU, memoria, ancho de banda, contadores de error y RX en dBm tanto para los puertos de la OLT como para las ONU.
La advertencia sobre escala tampoco era teórica. La C300 lleva bastante más de 300 ONU, y la ejecución del poller para ese equipo se alargó visiblemente en cuanto cada ONU se convirtió en sensores, así que los datos por ONU se están moviendo a Components y solo la óptica de la OLT se queda como sensores normales. Yo lo llamaría parcial más que resuelto: funciona, pero es mi propio conjunto de parches, y para el C320 no hay nada ya hecho.
Fabricante distinto, misma lección de mi lado: en cuanto un equipo sí te da números, compáralos con el otro extremo antes de construir alertas encima.
Tuvimos dos enlaces de 20 km con SFP+ no Juniper entre un EX4550 y un par de EX3300. Ambos enlaces pasaban tráfico, pero en el EX4550
show interfaces diagnostics opticsimprimíamientras que el extremo EX3300 de la misma fibra reportaba 0,1196 mW / -9,22 dBm. Eso es un defecto de escalado de Junos en el EX4550, PR1007055, corregido en 12.3R8. Hasta que actualizamos tratamos la lectura del EX4550 como decorativa y usamos el otro extremo.
De segunda mano, así que tómalo con cautela: en el ICX 7450 y el ICX 7550 la monitorización óptica supuestamente se queda en blanco para las referencias suministradas por Ruckus 33211-100 y 33210-100, mientras que los equivalentes codificados como Brocade en el mismo chasis reportan con normalidad, seguido como FI-264785 con una corrección esperada hacia un build 08.0.95j. Vale la pena un
show opticantes de que alguien empiece a reasentar módulos.