SONiC décode un QSFP-DD CMIS 4.0 avec des champs constructeur illisibles, alors que les modules SFF sont analysés correctement

Sur quelle branche êtes-vous ? Il existe des incohérences connues de noms de clés entre show interfaces transceiver eeprom et sfputil dans la 202012, corrigées dans la 202205, et il vaut la peine d'écarter cette piste avant de creuser plus loin.

Publiez la sortie de sudo sfputil show eeprom -d pour le même port. Si sfputil renvoie les mêmes chaînes illisibles, le problème vient du chemin de décodage partagé. S'il renvoie une erreur à la place, vous êtes dans un cas différent - nous avons des plateformes où il répond simplement Cannot get Module EEPROM data: Invalid argument sans jamais aller jusqu'au décodage.

J'ai exécuté les deux : sudo sfputil show eeprom -d et show interfaces transceiver eeprom -d sur le même port. Le même brouillage, les mêmes champs, les mêmes données incohérentes là où devrait figurer le numéro de série. Aucun Invalid argument nulle part, la lecture elle-même se déroule sans problème.

Les deux commandes sont donc d'accord entre elles, elles sont simplement d'accord sur une réponse fausse. Les ports QSFP28 voisins restent propres avec les deux commandes, ce qui laisse penser que le problème est spécifique à ce module CMIS plutôt qu'à la plateforme.

Ce schéma est la signature d'un analyseur appliqué à une carte mémoire qu'il ne comprend pas : une référence se trouvant dans le champ du nom constructeur, un numéro de série illisible, connecteur et encodage décalés. Un module défectueux ou une lecture I2C défaillante donne une erreur ou un bloc de zéros, pas des chaînes proprement erronées.

Le chemin de décodage se trouve dans sonic_platform_base/sonic_sfp/sfputilbase.py, et là, les trois chaînes d'identité sont extraites à des décalages codés en dur d'après l'ancienne carte SFF, quel que soit le module réellement branché. Un QSFP-DD CMIS 4.0 ne conserve pas son bloc d'identité à ces adresses - la spécification CMIS 4.0 le décrit dans la section 8.3 - donc le code lit bien des octets réels du bon module, simplement pas ceux qu'il croit lire, et il affiche ce qui occupe cette plage. C'est aussi pour cela que rien n'échoue jamais proprement : aucune étape ne regarde l'octet d'identifiant pour basculer vers une disposition CMIS.

La conclusion pratique est que rien, à part un analyseur qui comprend la carte CMIS, ne donnera un résultat correct, et tant que cela n'arrivera pas dans votre branche, la sortie CLI pour ce module n'est pas fiable pour l'inventaire. Pour la base d'actifs, lisez les pages en brut et décodez-les vous-même plutôt que de récupérer les données depuis la CLI.

Pour une lecture brute, c'est le pilote optoe qu'il vous faut : il expose les EEPROM SFP, QSFP et CMIS en lecture et écriture directes, ce qui permet de récupérer les octets et de les décoder dans votre propre script. C'est actuellement la seule source que j'alimenterais dans une base d'actifs pour des modules CMIS.

Une mise en garde si vous cherchez des décalages. Le tableau que tout le monde cite est celui du SFF - octets A0h 20-35 pour le nom constructeur, 40-59 pour PN, révision et SN. Ce sont exactement les décalages qui produisent vos données incohérentes sur un module CMIS, donc ne les réutilisez pas là. Même prudence sur un hôte Linux utilisé comme outil de banc : ethtool -m pour la vue décodée et ethtool -e pour les octets bruts conviennent pour les modules SFP, mais vérifiez ce que votre build comprend réellement avant de faire confiance aux champs affichés pour le CMIS.

La gestion du CMIS est fragile à plus d'un endroit que le décodeur d'EEPROM. Nous avons mis en service un plateau d'optiques InnoLight QSFP-DD 800G, T-DP8CNH-NNO et T-DP8CNT-NNO, et environ une insertion sur deux nous laissait avec un port mort : les chemins de données signalaient DataPathDeactivated, le journal indiquait un timeout pour « ConfigSuccess », et à partir de là le port restait down définitivement - aucune nouvelle tentative, rien qui le rétablisse de lui-même.

Le coupable s'est révélé être decommission_all_datapaths() dans cmis.py. Il déroule toute la séquence à la suite - DEINIT, ID d'application remis à 0, puis INIT - sans jamais vérifier qu'une étape a réellement pris effet avant de démarrer la suivante. Nos modules ont justement besoin de cette confirmation, si bien que le chemin de données reste à moitié configuré et que la machine à états attend simplement l'expiration de son minuteur. Un vrai correctif doit attendre de façon asynchrone, puisqu'on ne peut pas bloquer à l'intérieur de la machine à états CMIS en ligne de xcvrd, et à ma dernière vérification, personne n'en avait livré un. Bug différent, même thème : un chemin CMIS greffé sur du code écrit pour des modules SFF.

Une correction sur la direction que prend ce fil, car les deux modes de défaillance sont constamment confondus. Cannot get Module EEPROM data: Invalid argument, ou un QSFP qui disparaît de sfputil après un cycle d'alimentation jusqu'à ce que le pilote soit corrigé, ou une plateforme qui n'implémente tout simplement pas get_transceiver_info - ce sont des lacunes de plateforme et de pilote, qui vous bloquent avant tout décodage.

Ce qui est décrit ici est l'inverse : une lecture complète et réussie, ensuite interprétée avec une mauvaise disposition de champs. Ne changez pas de modules et ne courez pas après des versions de pilote pour ça. Les octets à l'intérieur de ce module sont corrects, et n'importe quel outil qui les décode en CMIS vous montrera le numéro de série indiqué sur l'étiquette.