LibreNMS non trova sensori ottici sugli OLT ZTE ZXA10 C300/C320 e nessuna interfaccia ONU
Mi occupo del livello di accesso in un piccolo ISP e vorrei che i nostri due OLT GPON comparissero nel monitoraggio come tutto il resto. La lista dei desideri non è esotica: quanto scalda lo chassis, carico CPU e RAM, contatori per porta, e la parte a cui tengo davvero, il lato ottico. Questo significa dBm Rx/Tx per le porte dell'OLT stesse e un valore Rx per ogni ONU abbonato.
- ZTE ZXA10 C300 e ZXA10 C320, community SNMP v2c in sola lettura
- LibreNMS 25.8.0-dev, poller self-hosted sullo stesso sito
- uplink SFP e SFP+ su entrambi gli OLT
Di serie non ottengo assolutamente niente sul lato ottico:
# discovery completes, device is green, but:
# - no transceiver Rx/Tx power sensors are discovered for either OLT
# - ONU interfaces do not exist in IF-MIB, only the OLT's own ports
snmpwalk -v2c -c <community> <olt> IF-MIB::ifDescrCosa ho già fatto:
- verificato che l'SNMP in sé sia sano, i grafici di traffico sugli uplink e sulle porte PON vengono disegnati correttamente
- riscoperto i dispositivi dopo ogni modifica e controllato le tabelle sensori standard, tutte vuote
- cercato un template pronto per la famiglia C320 e non ho trovato niente che copra le ottiche della porta GPON o delle ONU
Quindi: in quale albero pubblicano davvero questi apparati quei dati, sia per le loro porte sia per ONU, e qualcuno è riuscito a portarlo dentro LibreNMS in una forma che sopravvive a un aggiornamento?
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
Versione breve: niente di ottico su questi OLT vive in una MIB standard, sta tutto nell'albero enterprise privato ZTE 3902.
Comincia da quello facile, la temperatura dello chassis a .1.3.6.1.4.1.3902.1015.2.1.3.2. In giro c'è una definizione di sensore PHP con soglie 65/55/15/5 gradi. Non fidarti alla cieca, controllale contro quello a cui gira davvero il tuo chassis prima di collegarci sopra l'alerting.
Il lato ONU è il lavoro vero. IF-MIB descrive solo le interfacce dell'OLT, e una singola porta PON può portare fino a 128 ONU, quindi non c'è niente a cui agganciare un'interfaccia. Quello che la gente ha finito per fare è costruire l'indice impacchettando shelf, slot, porta e numero ONU in un unico intero:
e usarlo contro l'albero delle ONU:
Quell'albero porta i livelli RX delle ONU e contatori di byte Counter64, quindi il traffico per ONU esce dallo stesso walk.
Due avvertenze. Questo è un mucchio di patch utente, niente che sia arrivato upstream, quindi tieni le tue copie da qualche parte dove puoi riapplicarle dopo un aggiornamento. E un OLT con oltre 300 ONU moltiplica il numero di sensori per circa dieci, cosa che il poller nota eccome. A quella scala metti i dati delle ONU in Components invece che nelle interfacce normali.
Due domande prima che qualcuno ti scriva un template.
Hai fatto un walk di qualcosa fuori dalle MIB standard? Sulla famiglia ZXA10 i dati interessanti non stanno in IF-MIB, quindi una tabella sensori vuota è il risultato atteso, non un bug. Posta cosa ti torna da
Se quello restituisce un valore, sei a cavallo e il resto è aritmetica sugli indici.
Secondo: quante ONU per porta PON, e quante in totale per chassis? Quel numero decide se ti conviene usare sensori normali o qualcosa di più leggero, e cambia parecchio il consiglio.
Era quello. Il walk manuale su 3902 ha restituito valori subito, e dopo averlo collegato ora ho temperatura, CPU, memoria, banda, contatori di errore e dBm RX sia per le porte dell'OLT sia per le ONU.
Anche l'avvertimento sulla scala non era teorico. Il C300 porta ben oltre 300 ONU, e il giro del poller per quel dispositivo si è allungato visibilmente non appena ogni ONU è diventata un sensore, quindi i dati per ONU stanno migrando verso Components e solo le ottiche dell'OLT restano come sensori normali. Lo chiamerei ancora parziale piuttosto che risolto: funziona, ma è il mio patch set personale, e per il C320 non c'è niente di pronto.
Vendor diverso, stessa lezione dal mio lato: quando un apparato ti dà numeri, controllali contro il lato remoto prima di costruirci sopra l'alerting.
Avevamo due link da 20 km con SFP+ non Juniper tra un EX4550 e un paio di EX3300. Entrambi i link passavano traffico, ma sull'EX4550
show interfaces diagnostics opticsstampavamentre il lato EX3300 della stessa fibra riportava 0.1196 mW / -9.22 dBm. È un difetto di scaling di Junos sull'EX4550, PR1007055, corretto in 12.3R8. Finché non abbiamo aggiornato abbiamo trattato la lettura dell'EX4550 come decorazione e usato il lato remoto.
Di seconda mano, quindi prendetela con le pinze: su ICX 7450 e ICX 7550 il monitoraggio ottico a quanto pare resta vuoto per i part number forniti da Ruckus 33211-100 e 33210-100, mentre gli equivalenti codificati Brocade nello stesso chassis riportano normalmente, tracciato come FI-264785 con una correzione prevista intorno a una build 08.0.95j. Vale la pena un
show opticprima che qualcuno inizi a reinserire moduli.