Comment sur le ZXA10 C320 récupérer les données du module d'uplink et les niveaux des ONU - via CLI ou par SNMP

Précise ce dont tu as réellement besoin dans le monitoring. L'inventaire du module (vendor, référence, numéro de série) et la puissance dans le temps, ce sont deux histoires différentes : le premier suffit à relever une fois par jour et à stocker comme un fait, le second a du sens à interroger régulièrement et à tracer en graphique.

Et deuxième question, plus importante : le CRC sur l'uplink, tu l'as déjà regardé délibérément ou remarqué au passage ? Si le compteur grimpe vraiment, le niveau de réception n'est pas le principal suspect ici, et il faut commencer non pas par tracer des graphiques mais par cette interface.

Pour l'uplink, tout ce dont tu as besoin est justement donné par la commande que tu as trouvée :

show int optical-module-info xgei_1/21/1

Dans le résultat, il y a directement le nom du vendor, la référence, le numéro de série, et le type de module (par exemple 10GBASE-LR), la longueur d'onde 1310 nm, Rx et Tx en dBm, le courant de polarisation, la vitesse du laser et la température. En plus, les seuils d'alarme sur la puissance, le courant, la tension et la température sont là aussi - pas besoin d'aller chercher l'inventaire ailleurs.

Pour les abonnés, regarde l'atténuation pour une ONU précise :

show pon power attenuation gpon-onu_1/1/1:1

Pour le monitoring, la puissance de réception sur l'OLT se trouve à .1.3.6.1.4.1.3902.1015.1010.11.2.1.2 :

snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.1010.11.2.1.2

Il faut absolument diviser la valeur brute par 1000, sinon tu obtiens des milliers incompréhensibles au lieu de dBm. C'est là-dessus que trébuchent presque tous ceux qui tracent un graphique sur cet OID pour la première fois.

Et sur ton troisième point : avant de tirer des conclusions sur le niveau, regarde les compteurs CRC sur l'uplink. Un Rx normal en soi n'exclut ni un connecteur sale ni une liaison endommagée.

Diviser par 1000 - c'est exactement ce qui manquait. Sur mon graphique j'avais des milliers au lieu de dBm, et j'ai passé tout ce temps à penser que j'avais pris le mauvais objet.

Pour l'uplink, le tableau colle : module 10GBASE-LR, 1310 nm, niveau de réception normal, et le CRC grimpe quand même. Je suis allé voir le croisement - le connecteur était sale, après nettoyage le compteur s'est arrêté. Donc le conseil de regarder le CRC avant le niveau était pertinent.

Les niveaux pour une ONU précise se récupèrent bien avec la commande, je vais y accrocher une surveillance.

Sur le monitoring : n'attends pas de template tout prêt. La couverture du C320 est partielle d'origine - les ports GPON, l'optique des ONU et la longueur de ligne n'apparaîtront pas d'eux-mêmes. Dans LibreNMS (build 25.8.0-dev), un support correct de cette famille n'est jamais apparu : ni OID prêts, ni méthode documentée n'ont été publiés par qui que ce soit. Donc il n'y a qu'un chemin - tes propres objets et ton propre template, tu es déjà sur cette voie.

Au passage, garde en tête que sur du matériel différent ça s'appelle différemment. Sur un Cisco ISR 4451 il n'y a pas la commande habituelle depuis l'interface, la DDM est donnée via show hw-module subslot 0/0 transceiver 0 status, sur FortiGate c'est get system interface transceiver. Si tu construis un collecteur unique pour un parc multi-vendors, il est plus simple de tout tirer par SNMP partout, et de garder la CLI pour traiter une plainte précise.