Un ConnectX-4 MCX456A-ECAT ne se lie pas à un Cisco NCS en 100GBASE-LR4 alors que la boucle passe aux deux extrémités
Nous faisons tourner une paire de racks qui remettent le trafic à un Cisco NCS côté opérateur, et un des uplinks serveur 100G n'est jamais monté depuis la mise en service. Même résultat après avoir déplacé le serveur dans une autre armoire avec un panneau de brassage différent, donc j'ai arrêté de traiter ça comme un cas isolé.
- serveur Supermicro, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, les deux ports libres
- QSFP28 100GBASE-LR4 générique, monomode, portée 10 km, un à chaque extrémité
- Cisco NCS de l'autre côté, fibre noire entre les deux salles
Ce qui me bloque : chaque module passe une boucle sur son propre appareil. Avec la fibre bouclée directement dans le même QSFP28, la carte réseau rapporte un lien 100G propre, et le NCS fait de même de son côté. Mettez la vraie liaison entre les deux et il n'y a rien.
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noCe que nous avons déjà essayé :
- remplacé les deux modules par des pièces de rechange du même lot, aucun changement
- déplacé le serveur et rebrassé via un panneau différent
- ouvert un dossier auprès du vendor de la carte réseau, et la réponse a été un renvoi vers la liste des transceivers validés dans les notes de version du firmware, ce qui n'explique pas pourquoi la boucle fonctionne
Y a-t-il quelque chose de particulier au LR4 sur le ConnectX-4 qui lui permettrait de se lier localement mais jamais sur une vraie liaison, ou est-ce que je regarde du mauvais côté ?
Comments 3
Ça ressemble à un chemin sale, pas à un problème de compatibilité.
Tout ce que vous avez remplacé jusqu'ici se trouve du côté qui a déjà testé bon, ce qui explique pourquoi rien n'a changé - la liaison elle-même est la seule chose encore intacte. Donc travaillez le chemin :
La liste de transceivers validés qu'on vous a indiquée vaut un coup d'œil, mais un module qui monte proprement en boucle est déjà correctement piloté par la carte réseau. Les listes de compatibilité expliquent les modules carrément refusés, pas les modules qui se lient localement et meurent sur une vraie liaison.
Si le nettoyage ne suffit pas, l'étape suivante est une source lumineuse et un powermètre sur la fibre noire, ou une OTDR si vous pouvez en emprunter une, avant d'acheter une autre carte réseau ou une autre paire d'optiques.
Une boucle prouve seulement qu'un port peut s'entendre lui-même - laser, récepteur, réglages de débit. Elle ne dit rien sur le verre entre vos deux salles, et c'est la seule pièce que vous n'avez pas testée. Donc avant d'accuser à nouveau la carte réseau, prenez des chiffres aux deux extrémités avec la vraie liaison branchée : quelle est la puissance Rx sur le port du NCS, et quelle est-elle sur la carte réseau ? Un Rx sous le seuil Low Warn avec la liaison en place est le signe classique pointant vers l'extrémité distante ou le chemin plutôt que le port local. Côté Linux,
ethtool -mdevrait vous donner la même lecture, et s'il revient avecCannot get module EEPROM information: Input/output error, ne lisez pas ça comme un module mort - sur mlx5 c'est en général un accès au module côté firmware, etmst start,mst cable addpuismlxcablesvous donneront quand même les valeurs.Le nettoyage était la réponse. Nous avons mis un scope sur les faces d'extrémité et les deux modules plus les deux cordons de brassage étaient contaminés ; le cordon passant par le panneau inter-salles était le pire des deux. Nettoyé tout le chemin, réinséré, et le lien 100G vers le NCS est monté du premier coup et est resté up depuis.
Un peu agacé contre moi-même d'avoir passé autant de temps sur l'angle de la compatibilité alors que le résultat de la boucle me disait depuis le début que les modules étaient bons et que le chemin ne l'était pas. Pour quiconque atterrit ici plus tard : la boucle prouve le port, pas la fibre.