L'Edgecore AS5114-48X sous dentOS : le SFP+ du port 18 s'énumère bien mais onlpdump reste à RX_LOS
Nous gardons quelques boîtiers ONIE dans la baie de labo pour les tests, et l'un d'eux est un Edgecore AS5114-48X-O-AC-F-EC faisant tourner dentOS. Le port 18 est censé porter un lien 10G vers un switch voisin et il refuse tout simplement de monter, même si la plateforme voit clairement le module.
- Switch : Edgecore AS5114-48X-O-AC-F-EC, dentOS (ARM64)
- Module : Intel FTLX8571D3BCV-IT SFP+ dans le port 18
- Cordon LC duplex vers l'autre extrémité, du même lot que les cordons des ports qui fonctionnent
Le kernel est parfaitement content du module et la couche plateforme l'énumère, mais le bit de statut raconte une autre histoire :
kernel: ... port 18: switched to inband/10gbase-r link mode
$ onlpdump
...
sfp @ 18 = Present
Status: 0x00000004 [ RX_LOS ]Ce que j'ai déjà fait :
- réinséré le module et nettoyé les deux connecteurs
- inversé TX et RX à l'autre extrémité, puis remplacé tout le cordon par un connu bon
- déplacé le même module dans un autre port libre, même tableau là aussi
Donc l'EEPROM se relit bien et le côté MAC passe en 10gbase-r, mais le récepteur ne voit jamais de lumière. Comment séparer ça proprement entre le module, l'installation fibre et la plateforme, quand onlpdump ne me donne qu'un drapeau de présence et un masque de statut et rien d'autre ?
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 5
RX_LOS tout seul dit juste que le récepteur ne voit pas assez de lumière, donc avant de blâmer le boîtier : que rapporte l'autre extrémité ? Si le port pair expose la DDM, lisez sa puissance Tx et confirmez que le laser est bien allumé et que le port n'est pas shut. Ça vaut le coup de savoir aussi si les deux côtés ont le même type d'optique et le même mode de fibre - un module courte portée face à un longue portée, ou la mauvaise fibre, ressemble exactement à ça.
Et avez-vous essayé un second module d'une référence différente dans le port 18, ou seulement celui-ci déplacé entre ports ?
L'autre extrémité est un port 10G sur un autre switch, les mêmes optiques courte portée des deux côtés. Ce port se lie sans problème avec un module différent sur ce même cordon, donc le laser du pair est vivant et le chemin fibre est bon de bout en bout. Le port 18 est admin up, et j'obtiens le résultat identique avec le cordon inversé.
La partie agaçante est ce que je peux observer localement : onlpdump me donne présence plus le masque de statut, et c'est tout. Je n'ai aucun chiffre Rx côté dentOS à comparer à l'autre extrémité, donc je suis coincé à « quelque chose ne reçoit pas » sans savoir quel côté.
Du symptôme à la cause, dans l'ordre où je le traiterais. La détection prouve le chemin I2C/EEPROM et la plomberie MAC, rien d'autre. La ligne du kernel sur inband/10gbase-r est le côté hôte qui se configure lui-même - ça ne veut pas dire qu'un seul photon est arrivé. Avec RX_LOS asserté, il reste trois suspects : une fibre morte ou croisée, une autre extrémité qui ne transmet pas, et un récepteur qui ne fonctionne pas sur cette plateforme.
Vous avez déjà bien poussé sur les deux premiers, donc arrêtez de collecter des bits et obtenez un chiffre. N'importe quel switch qui affiche des diagnostics numériques fera l'affaire. Sur EXOS c'est
show ports <port> transceiver information, qui donne température, tension d'alimentation, courant de polarisation du laser, puissance Tx et Rx et signale chaque valeur en dehors des seuils du module, etdebug hal show optic port <port>ajoute le vendor, la référence, le numéro de série, le connecteur et la longueur d'onde depuis l'EEPROM. J'ai traqué un port 10G mort sur un X460-G2-24x-10G4 de cette façon et trouvé environ -26,78 dBm au récepteur, sur quoi aucun récepteur 10G courte ou longue portée ne va s'accrocher.Si l'autre extrémité peut vous donner une lecture Rx pendant que votre module transmet, vous apprenez au moins si son laser fonctionne. Ce qui reste après ça, c'est que la plateforme ne pilote pas correctement cette pièce précise.
Même boîtier ici, et sur cette plateforme le support des modules est par pièce, pas par standard. Sur notre AS5114-48X, l'Avago AFBR-703SDZ-IN2 rev G2.3 monte sans aucun réglage - la plateforme le rapporte comme Intel Corp avec le numéro de série AA1329A5UTA, ce qui perturbe les gens au premier coup d'œil.
Deux pièces n'ont jamais fonctionné chez nous dans le même switch sur la même fibre : l'Intel FTLX8571D3BCV-IT rev A que vous avez, et un OPNEXT TRS5020EN-S301. Les deux étaient détectés, les deux se comportaient exactement comme votre port 18. Empruntez une pièce connue bonne avant de passer une autre soirée sur l'installation fibre.
Ça vaut le coup d'être précis sur ce point : RX_LOS est la sortie de perte de signal propre au module telle que définie dans SFF-8472, et la couche plateforme ne fait que la faire remonter comme statut 0x00000004. Elle s'active en dessous du seuil LOS du récepteur, donc ça vous dit « pas assez de lumière » et jamais pourquoi. C'est aussi pour ça qu'une lecture EEPROM parfaitement propre et un chemin optique mort coexistent sans contradiction.
L'autre raison d'insister pour un vrai chiffre Rx : l'atténuation ressemble en tout point à de l'incompatibilité depuis la CLI. Un collègue avait un port Zyxel autour de -25,69 dBm, et la correction était le cordon de brassage plus un panneau de brassage que quelqu'un avait retravaillé, pas le module. Si vous ne pouvez pas lire la DDM côté dentOS, lisez-la depuis l'autre extrémité ou depuis un hôte - un masque de bits seul ne réglera pas ça.