Supermicro E300-9A sous pfSense Plus 22.05 : ix2 et ix3 restent en no carrier avec un DAC qui lie très bien sur un USW-Aggregation
Mon firewall est un Supermicro E300-9A faisant tourner pfSense Plus 22.05, et les deux ports 10G SFP+ refusent de monter. Ni ix2 ni ix3 n'affichent jamais de carrier, peu importe ce que je mets dans la cage.
Matériel :
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M et un câble twinax passif 10Gtek
- modules fibre Supermicro AXS85-192-M3 comme alternative
- Ubiquiti USW-Aggregation côté switch
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 a l'air pareil.
Essayé jusqu'ici :
- les deux câbles fonctionnent sur l'USW-Aggregation entre d'autres appareils, donc ils ne sont pas morts
- remplacé le cuivre par les modules fibre AXS85-192-M3, même no carrier sur les deux ports
- redémarré l'appliance plusieurs fois, y compris en insérant un module pendant qu'elle tournait
Y a-t-il quelque chose dans ce boîtier qu'il faut secouer avant que les cages se mettent à fonctionner, ou est-ce que je regarde deux ports morts ?
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 4
Les redémarrages à chaud ne mèneront nulle part - ces ports verrouillent un état de média et ne re-sondent jamais au redémarrage. Éteins l'appliance proprement, débranche l'adaptateur d'alimentation pendant deux minutes, puis rallume-la avec le module déjà inséré. C'est ce qui a ramené les deux ports ici, et une autre personne a décrit un comportement identique sur un port Intel X552, c'est pourquoi je pense que c'est un état de média périmé plutôt qu'un problème pfSense.
Si tu insères un module pendant que le système tourne déjà, fais rebondir l'interface plutôt que de redémarrer :
Ça fait regarder au driver la cage à nouveau. Ce n'est pas une correction permanente de quoi que ce soit, mais ça évite un redémarrage quand tu échanges des modules sur le banc. Vérifie le résultat avec
ifconfig -aplutôt qu'avec le panneau avant.Fais d'abord la coupure complète de l'alimentation et confirme les deux cages avec un DAC avant de toucher au côté switch. Déboguer une chose à la fois compte ici, parce que « no carrier avec chaque module » et « le lien monte à la mauvaise vitesse » sont généralement deux défauts séparés qui se trouvent être sur le même tronçon de câble.
La coupure complète de l'alimentation a fait l'affaire. Éteint, adaptateur débranché, attendu deux minutes, rallumé - les deux ports sont montés. Bouclé un DAC entre ix2 et ix3 et obtenu un lien 10G propre, et la paire AXS85-192-M3 fait aussi du 10G entre les deux ports, donc les cages et les modules sont bons.
Le côté switch, c'est une autre histoire. Vers l'USW-Aggregation, le lien ne négocie jamais qu'en 1G, et si je force le 10G d'un côté ou de l'autre, ça tombe et ça reste tombé. Donc la moitié du problème a disparu et la moitié agaçante est toujours là.
La moitié « repli en 1G » me paraît très familière. J'ai traqué le même symptôme sur un TL-SG3428X et un TL-SX3008F : redémarrer un serveur accroché à un de ces ports SFP+ et il revenait négocié en 1G peu importe ce pour quoi le port du switch était configuré. Adaptateurs Intel X520-DA2, Mellanox et HP, optiques Intel E10GSFPSR et 10GTek, mises à jour de firmware, plusieurs versions de driver sous Linux et Windows, profils de port - rien de tout ça n'a rien changé. Un redémarrage du switch, ou basculer la vitesse du port hors du 10G puis y revenir, restaurait le lien 10G jusqu'au prochain reset de l'hôte.
Ce qui a réellement corrigé ça, c'est de changer les optiques plutôt que quoi que ce soit côté hôte : des modules TP-Link SM5110-SR côté switch et le lien est revenu en 10G à chaque fois. Quelqu'un d'autre a confirmé la même chose sur un SG3428XMPP. L'interprétation était que le switch négocie mal avec certains modules tiers après un reset de lien côté hôte.
Vendeur différent de ton côté, mais la forme correspond. Avant d'acheter un lot de quoi que ce soit, emprunte un seul module de marque Ubiquiti et teste un port sur le switch d'agrégation.
Sur le forçage du 10G : le faire d'un seul côté empire les choses, ça ne les améliore pas. Le pair essaie toujours de négocier et un réglage fixe ne lui donne rien contre quoi négocier, donc le lien reste simplement down - ce qui est exactement le comportement que tu décris. Fixe vitesse et duplex des deux côtés, ou d'aucun des deux.
Deux cas apparentés venant du monde MikroTik, au cas où ça sonnerait une cloche. Sur un RB4011, un Finisar FTLF8524P2BNV-BR était détecté avec sfp-rx-loss et sfp-tx-fault tous les deux à no, et l'interface disait quand même no-link, parce qu'un SFP 1G dans une cage SFP+ doit être fixé plutôt que négocié :
et, encore une fois, des deux côtés. Le second était un CCR1072 où l'auto-négociation restait sur DONE après une perte de lien et le driver ne la relançait jamais ; désactiver l'autoneg et fixer la vitesse a ramené le lien, au prix d'une vraie détection de link-down.