La découverte LibreNMS sur un Nokia 7705 échoue avec Column 'channels' cannot be null et ne collecte aucun DOM
Nous interrogeons quelques routeurs d'agrégation Nokia 7705 dans LibreNMS et je voulais le DOM optique dessus pour la raison habituelle - repérer une liaison qui se dégrade avant que le client ne le remarque. La découverte ne se termine jamais sur ces appareils.
- Nokia 7705 sous TiMOS
- LibreNMS 26.3.1
- SFP 1G monovoie ordinaires dans les ports, vendors mixtes, certains anciens
- SNMP par ailleurs en bonne santé : interfaces, CPU, mémoire et trafic s'interrogent bien
La découverte s'arrête ici à chaque fois :
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be nullet le résultat est aucune entrée de transceiver et aucun capteur optique pour tout le routeur - pas un seul mauvais port avec le reste qui fonctionne, l'appareil entier revient vide.
Ce que j'ai essayé :
- relancé la découverte pour cet appareil seul, même erreur au même endroit
- supprimé et rajouté l'appareil : il est créé, puis la découverte meurt au même endroit
- d'autres vendors dans la même installation découvrent les transceivers et le DOM normalement, donc ça ne ressemble pas à une base de données cassée de mon côté
Est-ce un problème connu de découverte TiMOS, et y a-t-il quelque chose à faire à ce sujet avant de désactiver la découverte de transceiver pour ces routeurs ?
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 3
Connu, et ce n'est pas votre base de données.
Le code de découverte TiMOS extrait le nombre de voies depuis TIMETRA-PORT-MIB::tmnxPortSFPNumLanes et dépose tel quel ce qu'il obtient dans la colonne
channels, qui n'accepte pas NULL. Les optiques monovoie plus anciennes sont les coupables habituels : l'agent ne remplit jamais cet objet pour elles, donc le port fournit un null à l'insertion, l'insertion échoue, et l'échec entraîne avec lui toute la découverte de transceivers de l'appareil. C'est pour ça que vous perdez tous les ports plutôt que juste celui avec le module bizarre.Deux façons de s'en sortir. La plus propre est de faire avancer LibreNMS - le changement accepté en amont protège la valeur dans LibreNMS/OS/Timos.php, de sorte qu'un nombre de voies absent ou vide soit lu comme un seul canal et que tout le reste soit forcé en entier. Si vous êtes bloqué sur votre version actuelle, mettez la même protection dans ce fichier à la main ; ça fait quelques lignes, même si ça disparaîtra à la prochaine mise à jour si vous oubliez qu'elle est là.
Avant de patcher quoi que ce soit, parcourez TIMETRA-PORT-MIB::tmnxPortSFPNumLanes sur le routeur. Les ports qui répondent par rien du tout sont ceux qui font échouer l'insertion, et ça vaut la peine de savoir quelles optiques s'y trouvent.
Confirmé sur les deux points, merci.
En parcourant cet OID : les ports avec les optiques 1G les plus anciennes ne renvoient rien du tout pour le nombre de voies, tout ce qui est plus récent répond par 1. Donc le null vient bien des modules dont j'ai hérité, exactement comme décrit.
Après être passé à une version qui a la vérification, la découverte va jusqu'au bout sur tous les 7705, les transceivers apparaissent avec un seul canal chacun, et les capteurs optiques sont désormais graphés. Aucun changement côté routeur, aucun port exclu.
Deux choses à anticiper maintenant que la découverte se termine.
Le DDM chez Nokia est conditionné par un drapeau de capacité dans l'EEPROM du module. C'est l'approche maison à travers les familles de produits, et c'est énoncé le plus clairement dans le guide d'interfaces du 7210 SAS : la plateforme affichera volontiers des diagnostics pour un module qui ne pose jamais le drapeau, tout en disant dans le même paragraphe qu'elle n'a pas validé ni vérifié ces chiffres. Boîtier différent du vôtre, même logique - des chiffres RX/TX plausibles sur une optique tierce ne prouvent pas que le calibrage est correct.
L'autre moitié, c'est le module lui-même. Le GLC-SX-MM n'a pas de page A2h, donc il n'y a rien à lire pour un quelconque poller ; le GLC-SX-MMD en a une, le D étant pour diagnostics. Un graphique en permanence plat et vide, à vérifier avant d'accuser le poller.