Adaptateur QSA dans une cage QSFP28 SONiC : l'optique 10G établit le lien mais ne remonte aucun DDM
Nous réutilisons un stock d'optiques 10G sur un commutateur whitebox sous SONiC, si bien que quelques cages QSFP28 sont équipées d'adaptateurs de type QSA (10GTek QSA-100A) recevant de simples modules SFP+ 10G. Mécaniquement et électriquement, cela fonctionne. C'est côté gestion que ça coince.
- commutateur : whitebox 1U, SONiC compilé pour cette plateforme
- adaptateurs : 10GTek QSA-100A, cage QSFP28 vers SFP+
- optiques : modules SFP+ 10G récupérés sur un commutateur d'accès mis hors service
- ces mêmes optiques se lisent normalement dans une cage SFP+ native sur une autre machine
Ce que je vois sur les ports adaptés :
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portCe que j'ai déjà essayé :
- remplacé l'adaptateur et l'optique par une deuxième paire, comportement identique ;
- déplacé la paire vers une autre cage QSFP28, même résultat ;
- vérifié que les optiques remontent des diagnostics complets dans un port SFP+ natif ailleurs.
Est-ce que l'absence de données de diagnostic est quelque chose qu'un adaptateur passif ne peut tout simplement pas transmettre, ou est-ce du côté du logiciel du commutateur ? Et si c'est logiciel, où faut-il chercher le correctif : dans la couche plateforme ou dans le code générique de transceiver ?
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 7
Avant que quelqu'un ne se plonge dans le code plateforme, une question qui coupe le problème en deux. Mettez un module QSFP28 natif dans cette même cage : obtenez-vous des diagnostics, ou le DDM est-il mort sur ce port quoi que vous y branchiez ?
Si le module natif se lit correctement, la cage et le chemin I2C sont sains et tout se ramène à la façon dont le pilote de port interprète ce qui arrive via l'adaptateur. Si le module natif revient vide lui aussi, arrêtez de lire la suite du fil, vous avez un défaut différent qui n'a rien à voir avec les adaptateurs.
Différence bien connue et assez banale dans l'interface de gestion, et l'adaptateur n'est pas le coupable ici.
Côté SFP, deux adresses I2C entrent en jeu : les données d'identification se trouvent à 0x50, la carte de diagnostic à 0x51. Un module QSFP garde tout sous 0x50 et accède au reste en changeant de page. Donc un pilote à qui on a dit que la cage est QSFP va chercher des pages à une seule adresse et ne demande jamais rien à 0x51. L'identification revient suffisamment plausible pour que le port monte, mais les diagnostics ne se résolvent tout simplement jamais, exactement la forme de ce que vous avez posté.
Le correctif se trouve dans la couche plateforme, pas dans l'optique et pas dans l'adaptateur. Chaque plateforme fournit sa propre implémentation de SfpUtil ; dans la vôtre, ce port doit être déclaré comme cage SFP au lieu de QSFP. Tant que personne ne fait cela, le DDM/DOM sur les ports adaptés reste vide. Une fois fait, le module est lu comme il le serait dans une cage SFP+ native.
Un lien actif sans rien derrière au niveau des diagnostics, c'est à quoi ressemble un logiciel défaillant sur ces ports. Ce n'est pas à quoi ressemble une optique limite.
Ça vaut le coup de nommer les normes, car la séparation devient alors évidente. Le côté SFP suit SFF-8472, où les diagnostics vivent dans leur propre carte mémoire accessible à la seconde adresse. Le QSFP et le QSFP28 suivent SFF-8636, et les modules plus récents le CMIS, où tout est accroché à une seule adresse derrière une sélection de page.
L'adaptateur ne peut pas faire le pont entre les deux. C'est une pièce passive, mécanique et électrique, les fils de gestion la traversent directement et rien ne les traduit au passage. L'hôte doit donc être informé de quel modèle mémoire s'applique avant de lire le moindre octet, et l'adaptateur n'a aucun moyen de le lui dire.
Pour comparaison, le même type de problème mord plus fort sur du matériel Dell ONIE. Un QSA 407-BBRO avec un SFP+ 10GBASE-SR 407-BBOU à l'intérieur (SFP-10GSR-85), dans les ports 40G d'un S4048-ON et dans n'importe quel port d'un S6010-ON, tous deux sous OpenSwitch OPX 3.1 dev2 :
opx-ethtool identifie correctement le média, marque le transceiver activé et qualifié, l'état admin up, les débits pris en charge 1000, 10000 et 40000 Mbps, et le port ne monte jamais, quels que soient le débit, le duplex ou l'autonégociation configurés, y compris les valeurs par défaut. Quelqu'un a ouvert une demande d'amélioration sur le dépôt platform-config d'OPX, faites fonctionner le QSA ici, et personne n'a jamais répondu. Elle est toujours ouverte.
Ce n'est pas un verrouillage constructeur ni une mauvaise optique. Cette cage n'est simplement jamais mise en mode adaptateur par le système d'exploitation réseau, et aucune combinaison de réglages d'interface ne le fera à votre place.
Lié, mais merci de ne pas mélanger les deux cas. Le message d'origine décrit un lien fonctionnel avec des diagnostics manquants : le chemin de données est correct, seule la lecture de gestion est fausse, et corriger le SfpUtil de la plateforme règle le problème. Le cas Dell est un port qui ne monte jamais du tout, parce que le profil de port pour cette cage n'est jamais appliqué au départ. C'est une couche plus bas et cela demande son propre correctif.
Quelqu'un qui rapproche les symptômes trop vite pourrait perdre une journée à réécrire du code de transceiver alors que son port est down pour une raison totalement différente.
Encore une variante où « l'adaptateur est une fonctionnalité logicielle » plutôt que mécanique. Sur un Z9264F-ON sous OS10 10.5.2.7, utiliser des adaptateurs QSA28 pour du média SFP+ 10G signifie mettre le port dans le même profil port-group qu'utilise un câble de breakout 4x10G :
Les profils port-group sur cette plateforme agissent sur des paires de ports QSFP28, donc appliquer le profil désactive le port partenaire de chaque paire. Un QSA28 est une interface unique et vous payez quand même le prix d'un breakout : 64 ports utilisables deviennent 32. Ni les guides utilisateur OS10 ni la fiche technique des optiques Dell ne documentent un mode QSA à port unique.
Si vous avez besoin de beaucoup de 10G natif sur cette machine, prévoyez la perte de 2:1 dès le départ ou installez un commutateur 10G séparé dans la baie.
Avant que quelqu'un ne commande un plateau de ces adaptateurs, je mettrais deux vérifications sur la liste. Est-ce que le système d'exploitation réseau déclare le support QSA pour cette plateforme précise, et si oui, que coûte son activation : des ports, des diagnostics, ou un profil qui entraîne la cage voisine avec lui. La compatibilité physique n'est jamais le problème, chacun de ces adaptateurs s'enfiche dans la cage sans broncher.
Les cas de ce fil ne diffèrent que par jusqu'où va le logiciel. Sur SONiC, vous avez quelque chose que vous pouvez corriger vous-même, déclarez le port comme SFP et les diagnostics reviennent. Sur les plateformes Dell ci-dessus, vous attendez le code plateforme de quelqu'un d'autre, et changer d'adaptateurs ou d'optiques n'y changera rien du tout.