LibreNMS ne trouve aucun capteur optique sur les OLT ZTE ZXA10 C300/C320 et aucune interface ONU du tout
Je m'occupe de la couche d'accès d'un petit FAI et je veux que nos deux OLT GPON apparaissent dans le monitoring comme tout le reste. La liste de souhaits n'est pas exotique : la chauffe du châssis, la charge CPU et RAM, les compteurs par port, et la partie qui me tient vraiment à cœur, le côté optique. Cela veut dire les dBm Rx/Tx pour les ports de l'OLT eux-mêmes et un chiffre Rx par ONU abonné.
- ZTE ZXA10 C300 et ZXA10 C320, communauté SNMP v2c en lecture seule
- LibreNMS 25.8.0-dev, poller auto-hébergé sur le même site
- uplinks SFP et SFP+ sur les deux OLT
D'emblée je n'obtiens rien du tout côté optique :
# 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::ifDescrCe que j'ai déjà fait :
- vérifié que le SNMP lui-même est sain, les graphiques de trafic sur les uplinks et les ports PON sont tracés correctement
- redécouvert les appareils après chaque changement et vérifié les tables de capteurs standard, toutes vides
- cherché un template prêt pour la famille C320 et n'ai rien trouvé couvrant les optiques des ports GPON ou des ONU
Alors dans quelle arborescence ces boîtiers publient-ils réellement ça, à la fois pour leurs propres ports et par ONU, et quelqu'un a-t-il réussi à l'intégrer dans LibreNMS sous une forme qui survit à une mise à jour ?
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
Version courte : rien d'optique sur ces OLT ne vit dans une MIB standard, tout est dans l'arborescence privée ZTE 3902.
Commencez par le plus simple, la température du châssis à .1.3.6.1.4.1.3902.1015.2.1.3.2. Il existe une définition de capteur PHP qui circule pour ça avec des seuils de 65/55/15/5 degrés. Ne les prenez pas pour argent comptant, vérifiez-les par rapport à ce que votre châssis affiche réellement avant d'y brancher des alertes.
Le côté ONU est le vrai travail. IF-MIB ne décrit que les interfaces de l'OLT, et un seul port PON peut porter jusqu'à 128 ONU, donc il n'y a rien sur quoi accrocher une interface. Ce que les gens ont fini par faire, c'est construire l'index à partir du shelf, du slot, du port et du numéro d'ONU emballés dans un seul entier :
et l'utiliser contre l'arborescence ONU :
Cette arborescence porte les niveaux RX des ONU et des compteurs d'octets Counter64, donc le trafic par ONU sort de la même marche.
Deux avertissements. C'est un tas de correctifs faits par des utilisateurs, rien qui soit remonté en amont, donc gardez vos copies quelque part où vous pourrez les réappliquer après une mise à jour. Et un OLT avec plus de 300 ONU multiplie votre nombre de capteurs par environ dix, ce que le poller remarquera. À cette échelle, mettez les données ONU dans les Components plutôt que dans des interfaces ordinaires.
Deux questions avant que quelqu'un vous écrive un template.
Avez-vous interrogé quoi que ce soit en dehors des MIB standard ? Sur la famille ZXA10, les données intéressantes ne sont pas dans IF-MIB, donc une table de capteurs vide est le résultat attendu plutôt qu'un bug. Postez ce que vous obtenez avec
Si ça renvoie une valeur, c'est gagné et le reste n'est que de l'arithmétique d'index.
Deuxièmement : combien d'ONU par port PON, et combien au total par châssis ? Ce chiffre détermine si vous voulez des capteurs ordinaires ou quelque chose de plus léger, et ça change pas mal le conseil.
C'était ça. Interroger 3902 à la main a renvoyé des valeurs immédiatement, et après avoir tout branché j'ai maintenant la température, le CPU, la mémoire, la bande passante, les compteurs d'erreurs et les dBm RX pour les ports de l'OLT comme pour les ONU.
L'avertissement sur l'échelle n'était pas théorique non plus. Le C300 porte bien plus de 300 ONU, et le passage du poller pour cet appareil est devenu visiblement plus long une fois que chaque ONU s'est transformée en capteurs, donc les données par ONU passent vers les Components et seules les optiques de l'OLT restent des capteurs normaux. Je qualifierais toujours ça de partiel plutôt que résolu : ça marche, mais c'est mon propre jeu de correctifs, et rien n'est prêt à l'emploi pour le C320.
Vendor différent, même leçon de mon côté : une fois qu'un boîtier vous donne effectivement des chiffres, vérifiez-les par rapport à l'autre extrémité avant de construire des alertes dessus.
Nous avions deux liaisons de 20 km avec des SFP+ non Juniper entre un EX4550 et une paire d'EX3300. Les deux liens transportaient du trafic, mais sur l'EX4550
show interfaces diagnostics opticsaffichaitalors que le côté EX3300 de la même fibre indiquait 0,1196 mW / -9,22 dBm. C'est un défaut d'échelle Junos sur l'EX4550, PR1007055, corrigé en 12.3R8. Jusqu'à la mise à niveau, nous avons traité la lecture de l'EX4550 comme de la décoration et utilisé l'autre extrémité.
De seconde main, donc à prendre avec précaution : sur ICX 7450 et ICX 7550, le monitoring optique resterait vide pour les références Ruckus 33211-100 et 33210-100 tandis que des équivalents codés Brocade dans le même châssis rapportent normalement, suivi sous FI-264785 avec un correctif attendu autour d'une version 08.0.95j. Vaut le coup de faire un
show opticavant que quelqu'un ne commence à réinsérer des modules.