TL-SG3428X-M2 (V1) : la cage SFP+ 26 ne donne aucun lien avec aucun TL-SM5310-T, la cage 27 clignote avec
Je m'occupe d'un petit réseau de bureau, une seule baie de brassage, et les quatre cages SFP+ de notre switch d'accès portent les liens 10G vers la baie serveurs. Ça a tourné pendant des mois sans problème et maintenant une cage a tout simplement disparu.
- TP-Link TL-SG3428X-M2 (V1), firmware 1.20.4 Build 20241104 Rel.40746, adopté dans Omada
- quatre modules TP-Link TL-SM5310-T 10GBASE-T dans les ports SFP+ 25-28
- cordons CAT6A, les extrémités distantes sont deux serveurs et un NAS
États des ports actuellement :
port 25 up, 10G
port 26 down, no link LED with any module
port 27 up, 10G, but drops for a moment whenever a cable goes into or out of port 26
port 28 up, 10GCe que j'ai essayé :
- fait tourner les modules dans les quatre cages : le module de la 26 monte sans problème en 25 et en 28, et tout module que je mets en 26 reste éteint, donc les modules eux-mêmes sont sains
- nouveaux cordons de brassage, ports distants différents, aucun changement
- redémarrage du switch, désactivation/réactivation du port, aucun changement
Ce que je n'arrive pas à expliquer, c'est que le port 27 tressaute alors que la seule chose que je touche est le port 26. La cage 26 est-elle morte et mérite-t-elle un RMA, ou y a-t-il autre chose à écarter d'abord ?
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 6
C'est une régression de firmware dans la 1.20.4 Build 20241104, pas du matériel mort. Le schéma que vous décrivez - une cage SFP+ qui ne s'allume jamais avec des modules dont on sait qu'ils sont bons, plus une voisine qui a des ratés quand on touche à la cage morte - c'est exactement ce que fait cette version avec les modules cuivre TL-SM5310-T.
Revenez à la version précédente sur le switch et les ports reviennent. En pratique :
Chez TP-Link, on a reconnu qu'il y avait un problème dans cette version sur les switches Omada adaptés au contrôleur v5.14, dit que c'était en cours d'examen, et conseillé de rester sur l'ancien firmware pour l'instant. Donc ne gaspillez pas un dossier support sur le matériel, dépensez-le sur le numéro de build.
Si vous ne pouvez vraiment pas rétrograder, le seul contournement est de vivre avec les trois cages qui fonctionnent encore et de laisser le port 26 vide. Ce n'est pas une correction, juste un moyen de rester en service jusqu'à ce qu'une version corrigée apparaisse.
Avant de remplir un formulaire de RMA : quand est-ce que ça a commencé, et est-ce que le switch a reçu une mise à jour de firmware à peu près au même moment ? La 1.20.4 Build 20241104 est plutôt récente, et le contrôleur pousse volontiers une nouvelle image tout seul si les mises à jour automatiques sont restées activées.
Autre point à préciser : est-ce que le port 27 tressaute seulement quand la 26 a un module dedans, ou aussi quand la 26 est vide ? Une cage morte ne fait normalement pas flapper une voisine. Ça sent beaucoup plus le logiciel derrière les ports qu'une soudure fissurée.
Même switch, même version ici, donc vous n'êtes pas seul. Le port 25 allait bien, le port 26 n'avait aucune LED de lien avec tous les modules que je possède, et les 27 et 28 allaient et venaient - l'un d'eux alimente un EAP783, donc chaque coupure était très visible. J'ai fait exactement le même rituel d'échange de modules et je me suis convaincu d'avoir une cage morte.
Ce n'était pas la cage. L'appareil avait reçu une mise à jour de firmware peu avant que les problèmes commencent, et revenir à l'image précédente a fait revenir les quatre ports SFP+. Vérifiez l'historique des mises à jour avant d'expédier quoi que ce soit où que ce soit.
Confirmé, et c'est gênant à quel point j'étais près d'expédier le switch. L'historique des mises à jour montre que la 1.20.4 Build 20241104 est arrivée quelques jours avant que les ports deviennent bizarres, et je ne l'ai jamais lancée à la main, donc elle est arrivée toute seule.
Revenu à la version précédente, ré-adopté, et les quatre cages sont montées à 10G, port 26 inclus. Le port 27 ne tressaute plus quand je travaille sur la 26. Les mises à jour automatiques sont désactivées maintenant et l'ancienne image se trouve sur le serveur de fichiers à côté de la sauvegarde de config.
Pour les archives : la même famille a un autre piège de firmware à connaître. Sur un TL-SX3008F (V1) avec un SM5310-T(UN) alimentant un poste de travail, les firmwares 1.20.2 et 1.20.3 laissaient le port SFP+ mort dès que le PC passait en veille ou s'éteignait. Déplacer le module vers une cage libre fonctionnait exactement une fois par cage, et une fois toutes les cages utilisées, seul un redémarrage du switch faisait revenir les ports. Forcer le port en 1G évitait le problème, au prix de la vitesse pour laquelle vous aviez payé.
Un autre propriétaire a rencontré la même chose avec des modules RJ45 de 10Gtek (ASF-10G2-T), Wiitek et Xicom derrière un adaptateur Iocrest AQC113. Rétrograder vers la 1.20.0 Build 20231011 Rel.42220 a réglé le problème pour nous deux. Symptôme différent, même leçon : c'est dans la gestion du SFP+ cuivre que se cachent les bugs de ces versions.
Gardez encore une chose en tête avec cette gamme de switches : un module inactif peut vous coûter plus qu'un port. Sur un TL-SX3016F sous 1.0.0 Build 20210730 Rel.65115, le CPU restait à 87-89 % sans aucun trafic et déposait une ligne CPU RISING THRESHOLD dans le journal toutes les trois minutes.
La charge suivait le nombre de modules installés - un module 0-1 %, deux 73-76 %, trois ou plus 88-90 % - et ça se résumait à des modules Mellanox MFM1T02A-SR avec la fibre branchée mais rien d'allumé à l'autre bout, donc le lien restait down. Remplacer ces modules par des Ubiquiti UF-MM-10G maintenait le CPU bas quoi que fasse le port, et simplement retirer les modules inutilisés réglait aussi le problème. La réponse de TP-Link elle-même était qu'un module qui reste là avec son lien down coûte simplement cher au chipset, et que la charge redescend une fois le port correctement lié. Ça laisse la moitié gênante inexpliquée : changez de marque, laissez le module tout aussi inactif, et le CPU reste calme. Donc une fois revenu sur l'ancien firmware, jetez aussi un œil au graphique du CPU.