Zyxel RGS200-12P affiche « % SFP module doesn't support DDMI » pour deux SFP Avago
On livre des armoires industrielles avec la supervision propre du client par-dessus, donc un DDMI lisible sur les ports d'uplink fait partie de la liste de recette. Sur un RGS200-12P, les deux ports qui comptent refusent d'afficher quoi que ce soit une fois le DDMI activé, alors que les deux liens sont up et transmettent.
- Zyxel RGS200-12P, DDMI activé
- port 1/9 : AVAGO ABCU-5740RZ-HP8, SFP cuivre 1000BASE-T
- port 1/11 : AVAGO AFBR-5710PZ, 1000BASE-SX
- les deux liens up, compteurs propres des deux côtés
% SFP module doesn't support DDMICe qui a déjà été fait :
- désactivé le DDMI puis réactivé, sauvegardé, rechargé le switch
- réenfiché les deux modules et déplacés dans d'autres cages - même réponse sur chaque port
- vérifié que les liens eux-mêmes sont bons, le trafic passe sans erreurs
Donc c'est lequel : le switch qui refuse de lire des optiques qu'il n'a pas vendues, ou deux pièces Avago qui n'ont vraiment aucun diagnostic à donner ? Je dois donner au client une réponse ou l'autre avant la remise, pas un haussement d'épaules.
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
Tu as deux causes différentes cachées derrière une seule chaîne d'erreur.
Le port cuivre, c'est un comportement attendu. Les SFP 1000BASE-T en tant que catégorie n'implémentent aucun diagnostic numérique - il n'y a pas de puissance optique à rapporter et ces pièces ne portent généralement aucune page de diagnostic, donc 1/9 avec l'ABCU-5740RZ-HP8 n'affichera jamais température, tension ou puissance, peu importe comment le DDMI est configuré. Rien à corriger, rien à escalader.
Le port fibre, c'est le même résultat pour une raison différente : cette pièce Avago en particulier n'a pas de page DDM/DDMI dans son EEPROM. Le SFF-8472 rend la page de diagnostics optionnelle, et pas mal de modules 1000BASE-SX de cette génération sont sortis sans. Le switch ne bloque pas un module étranger ici, il rapporte la vérité - il n'y a rien dans le module à lire.
Le test qui règle ça en cinq minutes est celui déjà suggéré : un module spécifié comme compatible DDM dans la même cage. Un Zyxel SFP-LX-10-E dans un RGS200-12P affiche le bloc DDMI complet, ce qui prouve que le switch et la configuration sont bons. Mise en garde habituelle avec ce vendeur : leur position affichée est que les optiques tierces ne sont pas couvertes et peuvent apporter perte de paquets et problèmes de connectivité, donc si les diagnostics sont un critère de recette, mets « compatible DDM/DOM » dans le cahier des charges d'achat plutôt que d'espérer.
Si les optiques ne peuvent pas être changées sur cette armoire, surveille ces deux ports par état de lien et compteurs d'interface, et dis-le dans le document de remise. C'est une réponse honnête, et ça vaut mieux qu'une page DDMI vide que personne ne peut expliquer un an plus tard.
Deux choses valent la peine d'être séparées avant d'écrire quoi que ce soit. D'abord, est-ce que ce switch affiche le DDMI pour quoi que ce soit du tout ? Emprunte un module que tu sais compatible DDM, mets-le en 1/11 et lance la même commande. Si un bloc complet sort, le côté switch est prouvé et les deux pièces Avago sont la seule variable restante.
Ensuite, ne traite pas le module cuivre comme une preuve dans un sens ou l'autre, c'est une catégorie à part. Et que dit réellement la fiche technique de l'AFBR-5710PZ sur les diagnostics numériques ? Cette pièce est assez ancienne pour que je ne suppose pas qu'elle les ait du tout.
Confirmé sur le banc. Emprunté un SFP-LX-10-E, mis en 1/11 avec la même fibre, et le DDMI affiche tout le jeu - température, tension, courant de bias, puissance Tx et Rx. Remis l'AFBR-5710PZ et la chaîne d'erreur revient immédiatement. Le port 1/9 avec le module cuivre se comporte exactement comme avant, ce à quoi je m'attends maintenant plutôt que de chercher.
Donc le switch fait son travail et les modules sont la réponse. Ça part dans la remise comme une propriété du module, et la compatibilité DDM part dans le cahier des charges pour le prochain lot d'optiques. Ça m'a évité une dispute au sujet d'un switch « cassé ».
Ça vaut le coup de savoir que la même situation se lit complètement différemment selon la plateforme, ce qui explique pourquoi ça revient sans cesse comme rapport de bug.
Sur PAN-OS,
show transceiver-detail allaffiche un champdiagnostic-monitorpar module :Yesveut dire qu'il implémente la surveillance optique,Noveut dire que non, et dans le second cas le module est quand même identifié normalement pendant que chaque valeur de diagnostic revient enN/A. Pas d'erreur, juste des vides - bien plus facile à interpréter qu'une chaîne de refus.Sur un Nokia 7210 SAS, les valeurs manquantes peuvent être le logiciel plutôt : les premières releases n'implémentent pas du tout le DDM, et la documentation ajoute que pour les modules que Nokia n'a pas fournis, les données peuvent être affichées mais leur mise en forme et leur exactitude ne sont pas garanties. Trois responsables possibles pour un champ vide - module, plateforme ou release.
Et parfois c'est seulement l'interface : sur les switches TP-Link adoptés dans Omada il n'y a pas de page DDM dans le contrôleur, on ouvre son terminal, on tape
enableet on lanceshow ddm status.