El discovery de LibreNMS en un Nokia 7705 muere con Column 'channels' cannot be null y no recoge DOM
Sondeamos un puñado de routers de agregación Nokia 7705 en LibreNMS y quería el DOM óptico de ellos por la razón habitual - detectar un tramo degradándose antes de que el cliente lo note. El discovery nunca termina en esos equipos.
- Nokia 7705 corriendo TiMOS
- LibreNMS 26.3.1
- SFP de un solo carril de 1G normales en los puertos, fabricantes mixtos, algunos viejos
- SNMP por lo demás sano: interfaces, CPU, memoria y tráfico se sondean bien
El discovery se detiene aquí cada vez:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be nully el resultado es ninguna entrada de transceptor y ningún sensor óptico para todo el router - no un puerto malo con el resto funcionando, el equipo entero vuelve vacío.
Lo que he probado:
- volví a ejecutar el discovery para el equipo solo, mismo error en el mismo punto
- borré y volví a añadir el equipo: se crea, y luego el discovery muere en el mismo lugar
- otros fabricantes en la misma instalación descubren transceptores y DOM normalmente, así que no parece una base de datos rota de mi lado
¿Es un problema de discovery de TiMOS conocido, y hay algo que hacer al respecto aparte de apagar el discovery de transceptores para estos routers?
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 3
Uno conocido, y no es tu base de datos.
El código de discovery de TiMOS saca el número de carriles de TIMETRA-PORT-MIB::tmnxPortSFPNumLanes y mete lo que obtenga directo en la columna
channels, que no acepta NULL. Los ópticos antiguos de un solo carril son los culpables habituales: el agente nunca puebla ese objeto para ellos, así que el puerto le entrega un null al insert, el insert explota, y el fallo se lleva abajo con él todo el discovery de transceptores del equipo. Por eso pierdes todos los puertos en vez del que tiene el módulo raro.Dos salidas. La más limpia es avanzar LibreNMS - el cambio aceptado en el proyecto original protege el valor en LibreNMS/OS/Timos.php, de modo que un número de carriles ausente o vacío se lee como un solo canal y cualquier otra cosa se fuerza a entero. Si estás atascado en tu versión actual, mete la misma protección en ese archivo a mano; son un par de líneas, aunque desaparecerá con la siguiente actualización si olvidas que está ahí.
Antes de parchear nada, recorre TIMETRA-PORT-MIB::tmnxPortSFPNumLanes en el router. Los puertos que respondan con nada son los que están matando el insert, y vale la pena saber qué ópticos tienen puestos.
Confirmado en ambos puntos, gracias.
Recorriendo ese OID: los puertos con los ópticos de 1G más antiguos no devuelven nada para el número de carriles, todo lo más nuevo responde con 1. Así que el null viene de los módulos que heredé, exactamente como se describió.
Después de pasar a un build que tiene la comprobación, el discovery corre hasta el final en todos los 7705, los transceptores aparecen con un solo canal cada uno, y los sensores ópticos se están graficando. Sin cambios del lado del router, sin puertos excluidos.
Dos cosas que esperar ahora que el discovery termina.
El DDM en equipo Nokia está condicionado por una bandera de capacidad en la EEPROM del módulo. Ese es el enfoque de la casa en todas las familias, y se explica más claramente en la guía de interfaz del 7210 SAS: la plataforma imprimirá con gusto diagnósticos para un módulo que nunca fija la bandera, mientras dice en el mismo párrafo que no ha validado ni verificado esos números. Equipo distinto al tuyo, misma lógica - números RX/TX plausibles de un óptico de terceros no son prueba de que la calibración esté bien.
La otra mitad es el módulo mismo. El GLC-SX-MM no tiene página A2h, así que no hay nada que ningún poller pueda leer; el GLC-SX-MMD sí, la D es de diagnostics. Un gráfico permanentemente plano y vacío, comprueba eso antes que el poller.