La discovery di LibreNMS su un Nokia 7705 muore con Column 'channels' cannot be null e non raccoglie DOM
Interroghiamo in polling un pugno di router di aggregazione Nokia 7705 in LibreNMS e volevo il DOM ottico da loro per il solito motivo: intercettare una tratta che si sta degradando prima che se ne accorga il cliente. La discovery su questi dispositivi non finisce mai.
- Nokia 7705 con TiMOS
- LibreNMS 26.3.1
- normali SFP 1G a singola lane nelle porte, vendor misti, alcuni vecchi
- SNMP sano per il resto: interfacce, CPU, memoria e traffico vengono interrogati bene
La discovery si ferma qui ogni volta:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be null
e il risultato è nessuna voce transceiver e nessun sensore ottico per l'intero router: non una porta rotta con il resto funzionante, l'intero dispositivo torna vuoto.
Cosa ho provato:
- rilanciata la discovery per il singolo dispositivo da solo, stesso errore nello stesso punto
- cancellato e riaggiunto il dispositivo: viene creato, poi la discovery muore nello stesso punto
- altri vendor nella stessa installazione scoprono transceiver e DOM normalmente, quindi non sembra un database rotto dal mio lato
È un problema di discovery TiMOS conosciuto, e c'è qualcosa da fare a riguardo prima di disattivare del tutto la discovery dei transceiver per questi router?
Comments 3
Conosciuto, e non è il tuo database.
Il codice di discovery di TiMOS estrae il conteggio delle lane da TIMETRA-PORT-MIB::tmnxPortSFPNumLanes e lo butta così com'è nella colonna
channels, che non accetta NULL. Le ottiche più vecchie a singola lane sono i soliti colpevoli: l'agent non popola mai quell'oggetto per loro, quindi la porta passa un null all'insert, l'insert esplode, e il fallimento si porta dietro tutta la discovery dei transceiver dell'intero dispositivo. Ecco perché perdi ogni porta invece di quella sola con il modulo strano.Due vie d'uscita. La più pulita è portare avanti LibreNMS: la modifica accettata a monte protegge il valore in LibreNMS/OS/Timos.php, in modo che un conteggio di lane assente o vuoto venga letto come un singolo canale e qualsiasi altra cosa venga forzata a un intero. Se sei bloccato sulla tua release attuale, metti la stessa protezione in quel file a mano; sono un paio di righe, anche se sparirà al prossimo aggiornamento se ti dimentichi che c'è.
Prima di patchare qualsiasi cosa, percorri TIMETRA-PORT-MIB::tmnxPortSFPNumLanes sul router. Qualunque porta risponda con niente è quella che sta uccidendo l'insert, e vale la pena sapere quali ottiche ci sono dentro.
Confermato su entrambi i fronti, grazie.
Percorrendo quell'OID: le porte con le ottiche 1G più vecchie non rispondono niente per il conteggio delle lane, tutto quello più nuovo risponde con 1. Quindi il null viene proprio dai moduli che mi sono ritrovato in eredità, esattamente come descritto.
Dopo essere passato a una build che ha il controllo, la discovery arriva in fondo su tutti i 7705, i transceiver compaiono con un canale singolo ciascuno, e i sensori ottici vengono graficati. Nessuna modifica lato router, nessuna porta esclusa.
Due cose da aspettarsi ora che la discovery finisce.
Il DDM sull'hardware Nokia è vincolato da un flag di capability nell'EEPROM del modulo. È l'approccio di casa in tutte le famiglie, ed è spiegato nel modo più chiaro nella interface guide dei 7210 SAS: la piattaforma stampa allegramente diagnostica per un modulo che non imposta mai quel flag, dicendo nello stesso paragrafo di non aver validato né verificato quei numeri. Scatola diversa dalla tua, stessa logica: numeri RX/TX plausibili da un'ottica di terze parti non sono la prova che la calibrazione sia corretta.
L'altra metà è il modulo stesso. Il GLC-SX-MM non ha pagina A2h, quindi non c'è niente da leggere per nessun poller; il GLC-SX-MMD ce l'ha, la D sta per diagnostics. Un grafico permanentemente piatto e vuoto: controlla quello prima del poller.