Edgecore AS9716-32D : sfputil décode un module 400G QSFP-DD comme un QSFP28 sous PDDF
On met en service une paire d'AS9716-32D comme spine 400G en labo, sur une image SONiC communautaire avec la couche plateforme PDDF. L'optique n'est pas le problème, le lien avec le pair monte bien, mais tout ce que le switch dit à leur sujet est faux.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- build SONiC communautaire avec PDDF pour cette plateforme
- module 400G QSFP-DD (référence NeoPhotonics) dans la première cage
La lecture elle-même réussit, le module est listé, et la cage est signalée comme QSFP28 :
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsC'est cette ligne d'identifiant qui pose problème. C'est une référence QSFP-DD, donc les octets qui suivent sont décodés avec le jeu de champs SFF-8636 plutôt que CMIS, et les champs suivants ressemblent à du bruit.
Vérifié jusqu'ici :
- le module lui-même va bien, la même référence se lit correctement sur une autre plateforme et l'autre extrémité voit la lumière ;
- le ré-insérer et le déplacer vers une autre cage ne change rien, tous les ports 400G se comportent de façon identique ;
- dans la description d'appareil PDDF, ces cages sont déclarées comme QSFP28 et liées à optoe1.
Est-ce que ce dernier point est toute la réponse, les cages QSFP-DD ont-elles simplement besoin d'un autre périphérique optoe, et modifier la description de plateforme est-il la façon acceptée de corriger ça, ou quelque chose au-dessus doit-il aussi apprendre le type de cage ?
Comments 4
Votre symptôme correspond exactement au binding, donc pas besoin de chercher plus loin du côté de l'optique.
La description d'appareil PDDF pour l'AS9716-32D déclare les cages 400G comme QSFP28 et les lie à optoe1. optoe1 expose la disposition EEPROM SFF-8636 qu'utilisent les QSFP+ et QSFP28, donc un module CMIS est lu à travers la mauvaise carte mémoire et tout ce qui suit l'identifiant ressemble à du bruit. Le type de port que vous voyez n'est pas du tout détecté, c'est simplement ce que dit la description.
Le QSFP-DD suit le CMIS, et le CMIS est servi par optoe3. La correction consiste à basculer les deux champs dans la description d'appareil PDDF pour ces cages : le type de QSFP28 à QSFP-DD, et le driver de optoe1 à optoe3. Je l'ai vérifié sur le même boîtier avec une référence NeoPhotonics 400G, et après le changement,
sfputil show eepromrenvoie le module correctement décodé.Deux réserves. Ce sont des données de plateforme, donc une mise à jour d'image remettra volontiers l'ancienne description en place à moins que le changement ne soit dans l'image que vous construisez. Et en amont, ce changement exact a été approuvé mais la pull request a été fermée sans être fusionnée, le travail ayant été intégré dans un changement ultérieur, donc ne présumez pas que votre image le contient déjà. Lisez d'abord la description d'appareil de votre plateforme et vous saurez en une minute si vous avez quelque chose à chasser.
Avant de toucher à un quelconque fichier de plateforme, postez le dump brut :
sudo sfputil show eeprom -dsur ce port. Si tous les octets sont là et que seule l'interprétation est fausse, c'est un problème de binding et non un problème de module, et cette distinction vaut dix minutes avant que quiconque commence à parler de RMA.L'autre moitié, vous y avez déjà répondu vous-même. optoe1 est la variante SFF-8636 utilisée pour les QSFP+ et QSFP28, donc un module CMIS lu à travers lui ressort corrompu à partir de l'identifiant, ce qui est exactement la sortie que vous avez collée. Dès que la description nomme optoe1 pour une cage QSFP-DD, il ne reste plus rien à suspecter du côté du module.
Alors collez aussi les lignes pertinentes de la description d'appareil PDDF pour l'une de ces cages. Ça nous dira si seul le champ driver est faux ou aussi le type de cage déclaré.
C'était bien ça. Type de cage vers QSFP-DD, driver vers optoe3, reload, et le module se décode correctement maintenant,
sfputil show eepromn'appelant plus la cage QSFP28. J'ai mis le changement dans l'image que nous construisons plutôt que de patcher le switch en fonctionnement, précisément à cause du point sur les mises à jour évoqué plus haut.Une note honnête pour quiconque tombe là-dessus plus tard : ça corrige la façon dont l'EEPROM est lu, rien de plus. Le reste de la tuyauterie liée aux transceivers sur cette plateforme a encore ses propres bizarreries et je ne dirais pas que le boîtier est complètement réglé.
Puisque vous mentionnez les bizarreries restantes, en voici une qui vous attend sur la même plateforme. Sur notre AS9716-32D (x86_64-accton_as9716_32d-r0) qui tourne sur un build SONiC master,
sudo sfputil show presenceliste les ports peuplés comme Present et lit bien leur EEPROM, tandis queshow interfaces transceiver presencesignale tous les ports comme Not present. Le syslog répète :et lire l'EEPROM via la CLI échoue avec RuntimeError('PddfEeprom is not Programmed'). Ça apparaît aléatoirement après un redémarrage et aucune cause racine n'a jamais été publiée, donc sfputil reste la seule vérification de présence à laquelle je fais confiance là-dessus.
Sans rapport mais dans le même domaine : les deux commandes sont aussi connues pour ne pas s'accorder sur les noms de clés dans la branche 202012, ce qui a été nettoyé dans la 202205. Si vos sorties diffèrent dans la formulation plutôt que dans le contenu, c'est probablement juste ça.