OLT ZXA10 dans LibreNMS : aucun dBm de transceiver sur les pages de port, et les capteurs de ventilateur et d'alimentation ont disparu
On interroge un parc mixte d'OLT ZTE ZXA10 depuis LibreNMS et deux choses ne vont pas. Je soupçonne qu'elles sont sans rapport, mais je n'en suis pas sûr.
- ZTE ZXA10 C300 en V2.1.0, encore en service dans un vieux POP
- ZTE ZXA10 C620 en V2.0.30, plus un C650 et un C650E
- un ZTE ZXA10 C320 qui se comportait bien avant
- uplinks SFP et SFP+, cartes GPON en dessous
Premier problème : les pages de port n'ont aucun capteur de transceiver du tout. Pas de puissance de réception ou d'émission en dBm, pas de température de module, pas de tension d'alimentation, pas de courant de bias du laser. Ce sont les chiffres que je veux pour attraper un connecteur sale avant que les abonnés ne commencent à appeler.
Second problème : les capteurs d'état qui fonctionnaient sur le C320, ventilateurs, alimentations et état de carte, ont discrètement disparu après une redécouverte. Aucune erreur dans le log, rien n'a échoué, ils ne sont simplement plus sur l'appareil.
En parcourant les boîtiers à la main, les données optiques sont clairement dans la MIB quelque part, mais un OID qui répond sur une plateforme ne renvoie rien sur une autre :
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Essayé jusqu'ici :
- redécouverte et poll complet sur chaque appareil
- comparé ce que répond un C650 face à ce que répond le C300 sur le même OID
- vérifié si des cages vides sont la raison pour laquelle la découverte abandonne
Où vivent réellement les relevés optiques sur la famille ZXA10, et qu'est-ce qui fait disparaître un capteur d'état à la découverte sans rien logger ?
Comments 5
Les deux sont connus, et comme tu l'as deviné ils sont sans rapport.
Quelle table optique tu obtiens dépend de la plateforme, et les deux ne coexistent jamais sur un même boîtier. L'ancien C300, testé ici sur V2.1.0, expose zxAnOpticalModuleMonTable :
Le C620 en V2.0.30, le C650 et le C650E exposent zxAnOpticalModuleInfoTable à la place :
Chaque table te donne les quatre mêmes relevés : puissance rx et tx en dBm, température du module, tension d'alimentation, courant de bias du laser. Les valeurs brutes ont besoin de l'échelle 0,001. Deux sentinelles doivent aussi être filtrées, sinon chaque cage vide du châssis va t'alarmer : un port non supporté ou une cage non peuplée répond 2147483647, et un port éteint répond -80000. La présence de carte n'a rien à faire dans le polling optique, c'est un capteur d'état opérationnel séparé qui saute les slots non peuplés.
Tes ventilateurs, alimentations et état de carte disparus sont un bug différent. Les entrées d'état dans le YAML de plateforme n'avaient pas la clé value:, et sans elle la découverte finit par lire le nom de la table comme si c'était une colonne, ne trouve rien d'utilisable et abandonne le capteur silencieusement, aucune erreur nulle part, c'est pourquoi tu ne l'as remarqué que comme une absence. Remettre la clé a restauré six capteurs sur le montage C320 ici.
Mise en garde honnête avant que tu ne comptes dessus : ça circule dans un changement encore ouvert plutôt que fusionné, et la revue en a déjà retiré la surveillance des erreurs ethernet comme hors périmètre. Traite ça comme un patch que tu portes, pas comme une correction à attendre.
Montre-nous le sysDescr que rapporte chacun de ces boîtiers. C300, C320, C620, C650 et C650E ne sont pas une seule famille en ce qui concerne la MIB optique, donc un OID qui répond sur certains et reste silencieux sur les autres est attendu plutôt qu'un défaut.
Poste la fin d'un walk des deux qui diffèrent le plus, le C300 et l'un des C650, sur l'OID que tu as déjà essayé. Si l'un répond et l'autre est vide, c'est toute l'histoire et la correction est par plateforme.
Garde aussi tes deux problèmes séparés. Les capteurs de ventilateur et d'alimentation manquants sont un problème de définition de découverte et n'ont rien à voir avec la table optique que l'OLT implémente.
Je confirme l'écart de l'autre côté. J'ai posé la question sur cette même famille en 25.8.0-dev : un OLT GPON C320, et ce que je cherchais c'était le graphique sur les ports GPON aux deux bouts, sur l'OLT et sur les ONU - niveaux de puissance rx et tx, combien mesure chaque lien, utilisation par port - plus si un template pour la famille existait déjà quelque part.
Ça a été fermé sans que personne ne poste d'OID, de walk ou de méthode, donc tout ce que ça documente c'est que la couverture prête à l'emploi pour la famille C320 est partielle. Avec le recul, j'aurais dû joindre un walk à la demande. Si tu construis ça de toute façon, les niveaux optiques des ONU sont la partie que personne n'a faite et pas mal d'entre nous l'utiliseraient.
Ça correspond à ce que fait le parc. Le C300 répond sur .1.3.6.1.4.1.3902.1015.3.1.13.1 et ne renvoie rien sur l'autre OID, le C620 et le C650 sont l'inverse, et le C650E se comporte comme le C650.
Les valeurs reviennent en entiers nécessitant l'échelle 0,001, exactement comme décrit. Celles qui ressemblaient à du bruit au départ ont du sens maintenant : 2147483647 sur les cages qu'on n'a jamais peuplées, et -80000 sur deux ports où l'autre bout est éteint. Les deux sentinelles sont réelles ici, donc quiconque écrit des seuils sur les nombres bruts obtiendra une liste d'alertes très bruyante.
Vérifié aussi le YAML de plateforme et la clé value: manque de notre côté aussi. On va la porter localement puisque le changement est encore ouvert. Séparer les deux problèmes est la partie que j'avais mal comprise depuis le début.
Une chose à garder en tête en construisant ça : les données DOM sont un sous-ensemble partout, pas seulement chez ZTE.
Dans SONiC, un QSFP28 CISCO-AVAGO AFBR-89CDDZ-CS3 voit son EEPROM lue sans problème, et TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR plus TRANSCEIVER_STATUS se remplissent tous avec l'identité plus température, tension, bias et puissance par voie, mais le groupe contrôle et statut est simplement absent : get_rx_los, get_tx_fault, get_tx_disable, get_lpmode et get_power_override ne renvoient rien dans la vue base de données, donc si tu as besoin de ces bits, tu vas les demander toi-même à l'API de la plateforme.
Même leçon côté firewall. Sur PAN-OS, show transceiver-detail all affiche le bloc de diagnostic, et le premier champ à lire est diagnostic-monitor. S'il dit No, le module n'implémente pas la surveillance optique numérique et chaque valeur revient en N/A. Rien n'est cassé là, il n'y a simplement rien à lire. Ça vaut le coup d'encoder cette distinction dans tes alertes pour qu'un module sans DOM ne ressemble pas à un port mort.