Come leggere sul ZXA10 C320 i dati del modulo uplink e i livelli ONU - via CLI o SNMP
Gestisco sul nodo uno ZTE ZXA10 C320, uplink 10G. I livelli e lo stato li controllo a mano dalla console, ma vorrei portare tutto nel monitoraggio per non dover entrare in CLI a ogni reclamo di un abbonato.
- OLT: ZTE ZXA10 C320
- uplink: SFP+ in xgei_1/21/1
- abbonati su gpon-onu_1/1/1:1 e a seguire sui rami
Sul modulo dell'uplink qualcosa ho già trovato, l'output lo dà questo comando:
show int optical-module-info xgei_1/21/1Da qui in poi mi blocco su tre cose:
- con quale comando leggere il livello di una ONU specifica, invece di analizzare l'output di tutto il ramo
- se esiste un oggetto SNMP con la stessa potenza di ricezione, per non fare il parsing della CLI con uno script; un template pronto per il C320 nel monitoraggio non l'ho trovato
- quanto ci si possa davvero fidare del livello di ricezione: su un uplink il numero è decente, ma intanto il CRC sull'interfaccia sale piano piano
Chi legge questi dati dal C320 in modo continuativo: su cosa vi siete fermati, CLI o SNMP, e quali OID?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 4
Chiarisci di cosa hai davvero bisogno nel monitoraggio. L'inventario del modulo (vendor, partnumber, seriale) e la potenza nel tempo sono due storie diverse: il primo basta leggerlo una volta al giorno e tenerlo come dato fisso, il secondo ha senso interrogarlo regolarmente e disegnarlo su un grafico.
E la seconda domanda, più importante: il CRC sull'uplink l'hai già guardato di proposito o l'hai notato di striscio? Se il contatore sale davvero, il livello di ricezione qui non è il primo sospettato, e bisogna partire non dai grafici ma da questa interfaccia.
Per l'uplink ti dà tutto il necessario proprio il comando che hai trovato:
Nell'output trovi subito il nome del vendor, il partnumber, il seriale, il tipo di modulo (per esempio 10GBASE-LR), la lunghezza d'onda 1310 nm, Rx e Tx in dBm, la corrente di bias, la velocità del laser e la temperatura. In più ci sono le soglie di allarme per potenza, corrente, tensione e temperatura: non serve andare a cercare l'inventario da un'altra parte.
Per gli abbonati guarda l'attenuazione sulla singola ONU:
Per il monitoraggio, la potenza di ricezione sull'OLT si trova su .1.3.6.1.4.1.3902.1015.1010.11.2.1.2:
Il valore grezzo va assolutamente diviso per 1000, altrimenti invece dei dBm ottieni migliaia senza senso. Ci inciampano quasi tutti quelli che disegnano per la prima volta un grafico su questo OID.
E sul tuo terzo punto: prima di trarre conclusioni sul livello, guarda i contatori CRC sull'uplink. Un Rx normale da solo non esclude né un connettore sporco né una tratta danneggiata.
La divisione per 1000 era esattamente quello che mancava. Sul mio grafico avevo migliaia invece di dBm, e per tutto questo tempo ho pensato di aver preso l'oggetto sbagliato.
Sull'uplink il quadro torna: modulo 10GBASE-LR, 1310 nm, livello di ricezione normale, e intanto il CRC sale. Sono andato a controllare il permutatore: il connettore era sporco, dopo la pulizia il contatore si è fermato. Quindi il consiglio di guardare il CRC prima del livello si è rivelato azzeccato.
I livelli per la singola ONU si leggono col comando, ci metterò sopra un polling.
Sul monitoraggio: un template pronto puoi anche non aspettarlo. La copertura del C320 di serie è parziale - le porte GPON, l'ottica delle ONU e la lunghezza della linea non spuntano da sole. Su LibreNMS (build 25.8.0-dev) un supporto vero per questa famiglia non è mai arrivato: nessuno ha pubblicato né gli OID pronti né un metodo descritto. Quindi la strada è una sola - oggetti tuoi e template tuo, e ci stai già andando.
Tieni anche presente che su hardware diverso questo si chiama in modo diverso. Sul Cisco ISR 4451 non c'è il solito comando da interfaccia, il DOM lo dà
show hw-module subslot 0/0 transceiver 0 status, sul FortiGate èget system interface transceiver. Se stai costruendo un poller unico per un parco di vendor diversi, è più semplice tirare ovunque via SNMP e tenere la CLI per analizzare il singolo reclamo.