OLT ZXA10 in LibreNMS: niente dBm dei transceiver nelle pagine porta, e i sensori di ventole e alimentatori sono spariti
Interroghiamo una flotta mista di OLT ZTE ZXA10 da LibreNMS e due cose non vanno. Sospetto siano scollegate tra loro, ma non ne sono sicuro.
- ZTE ZXA10 C300 su V2.1.0, ancora in servizio in un vecchio POP
- ZTE ZXA10 C620 su V2.0.30, più un C650 e un C650E
- un ZTE ZXA10 C320 che prima si comportava bene
- uplink SFP e SFP+, con schede GPON sotto
Primo problema: le pagine porta non hanno alcun sensore del transceiver. Niente potenza in ricezione o trasmissione in dBm, niente temperatura del modulo, niente tensione di alimentazione, niente corrente di bias del laser. Sono proprio i numeri che voglio per beccare un connettore sporco prima che gli abbonati inizino a chiamare.
Secondo problema: i sensori di stato che funzionavano sul C320, ventole, alimentatori e stato scheda, sono spariti silenziosamente dopo una rediscovery. Nessun errore nel log, niente fallito, semplicemente non sono più sul dispositivo.
Girando i box a mano, il dato ottico sta chiaramente da qualche parte nella MIB, ma un OID che risponde su una piattaforma non ritorna niente su un'altra:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Provato finora:
- rediscovery e poll completo su ogni dispositivo
- confrontato cosa risponde un C650 rispetto a cosa risponde il C300 sullo stesso OID
- controllato se le cage vuote sono il motivo per cui la discovery rinuncia
Dove vivono davvero le letture ottiche sulla famiglia ZXA10, e cosa fa sparire un sensore di stato alla discovery senza loggare nulla?
Comments 5
Sono entrambi noti, e come hai intuito non sono collegati.
Quale tabella ottica ottieni dipende dalla piattaforma, e le due non coesistono mai sullo stesso box. Il C300 più vecchio, testato qui contro V2.1.0, espone zxAnOpticalModuleMonTable:
C620 su V2.0.30, C650 e C650E espongono invece zxAnOpticalModuleInfoTable:
Qualsiasi delle due tabelle ti dà le stesse quattro letture: potenza rx e tx in dBm, temperatura del modulo, tensione di alimentazione, corrente di bias del laser. I valori grezzi vanno scalati di 0.001. Vanno filtrate anche due sentinelle, altrimenti ogni cage vuota nello chassis ti manda in allarme: una porta non supportata o una cage non popolata risponde 2147483647, e una porta spenta risponde -80000. La presenza della scheda non appartiene affatto al polling ottico, quella è un sensore di stato operativo separato che salta gli slot non popolati.
I tuoi ventole, alimentatori e stato scheda spariti sono un bug diverso. Le voci di stato nello YAML della piattaforma non avevano la chiave value:, e senza di essa la discovery finisce per leggere il nome della tabella come se fosse una colonna, non trova niente di utilizzabile e scarta il sensore in silenzio, nessun errore da nessuna parte, motivo per cui l'hai notato solo come assenza. Rimettere la chiave a posto ha ripristinato sei sensori sulla fixture C320 qui da noi.
Avviso onesto prima che ci pianifichi sopra: questo viaggia dentro una modifica ancora aperta e non ancora mergiata, e la review ha già tolto il monitoraggio degli errori ethernet considerandolo fuori ambito. Trattala come una patch che ti porti dietro, non come una correzione da aspettare.
Facci vedere il sysDescr che riporta ognuno di questi box. C300, C320, C620, C650 e C650E non sono un'unica famiglia per quanto riguarda la MIB ottica, quindi un OID che risponde su alcuni e resta muto sugli altri è atteso, non un guasto.
Posta la coda di un walk dai due che differiscono di più, il C300 e uno dei C650, sull'OID che hai già provato. Se uno risponde e l'altro è vuoto, è tutta la storia e la correzione va fatta per piattaforma.
Tieni anche separati i tuoi due problemi. I sensori di ventole e alimentatori mancanti sono un problema di definizione della discovery e non hanno niente a che fare con quale tabella ottica implementa l'OLT.
Confermo il buco dall'altro lato. Ho chiesto della stessa famiglia su 25.8.0-dev: un OLT GPON C320, e quello che cercavo era il grafico sulle porte GPON su entrambi i lati, sull'OLT e sugli ONU - livelli di potenza rx e tx, quanto misura ogni link, utilizzo per porta - più se esistesse già da qualche parte un template per la famiglia.
È stata chiusa senza che nessuno postasse OID, un walk o un metodo, quindi tutto quello che documenta è che la copertura out-of-the-box per la famiglia C320 è parziale. Col senno di poi avrei dovuto allegare un walk alla richiesta. Se lo stai comunque costruendo, i livelli ottici degli ONU sono la parte che nessuno ha fatto e in tanti la useremmo.
Corrisponde a quello che fa la nostra flotta. Il C300 risponde su .1.3.6.1.4.1.3902.1015.3.1.13.1 e non ritorna niente sull'altro OID, C620 e C650 sono al contrario, e il C650E si comporta come il C650.
I valori tornano come interi che hanno bisogno della scalatura 0.001, esattamente come descritto. Quelli che sulle prime sembravano spazzatura ora hanno senso: 2147483647 sulle cage che non abbiamo mai popolato, e -80000 su due porte dove il lato remoto è spento. Entrambe le sentinelle sono reali qui, quindi chiunque scriva soglie contro i numeri grezzi si ritroverà una lista di allarmi molto rumorosa.
Ho controllato anche lo YAML della piattaforma e manca la chiave value: anche dal nostro lato. La terremo in locale visto che la modifica è ancora aperta. Separare i due problemi era la parte che avevo sbagliato fin dall'inizio.
Una cosa da tenere a mente mentre lo costruisci: i dati DOM sono un sottoinsieme dappertutto, non solo su ZTE.
In SONiC un QSFP28 CISCO-AVAGO AFBR-89CDDZ-CS3 fa leggere il suo EEPROM senza problemi, e TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR più TRANSCEIVER_STATUS si riempiono tutti con identità più temperatura, tensione, bias e potenza per lane, ma il gruppo di controllo e stato è semplicemente assente: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode e get_power_override non ritornano niente nella vista database, quindi se ti servono quei bit devi andare a chiederli tu stesso all'API della piattaforma.
Stessa lezione dal lato firewall. Su PAN-OS, show transceiver-detail all stampa il blocco diagnostico, e il primo campo da leggere è diagnostic-monitor. Se dice No, il modulo non implementa il digital optical monitoring e ogni valore torna N/A. Lì non c'è niente di rotto, semplicemente non c'è niente da leggere. Vale la pena codificare questa distinzione nel tuo alerting così un modulo senza DOM non sembra uguale a una porta morta.