Cage SFP+ du Turris Omnia NG : quels modules cuivre RJ-45 tiers lient réellement
J'ai un Turris Omnia NG à la maison et la dernière chose posée sur le port WAN métallique est un saut de deux mètres vers le routeur du FAI. J'aimerais déplacer ce saut dans la cage SFP+ et libérer le port cuivre pour le côté labo. Le module cuivre SFP+ officiel Turris (RTROM01-RTSF-10G) coûte à peu près le prix d'un petit switch et est franchement difficile à trouver.
Configuration :
- Turris Omnia NG, firmware d'origine, cage SFP+ actuellement vide
- court tronçon RJ-45 vers le routeur du FAI, en 1G de ce côté
- deux hôtes 10G côté labo que j'aimerais éventuellement atteindre plus vite que 1G
- aucun module cuivre SFP+ de rechange dans le tiroir pour tester
Tout ce que j'ai pour juger un module une fois qu'il arrive :
dmesg | grep -i sfp
ethtool -m eth2Ce que j'ai fait jusqu'ici : cherché une liste de compatibilité officielle pour la cage et rien trouvé, et demandé à un vendeur s'il reprend un module qui ne monte pas.
Donc la question est simple - quels modules cuivre RJ-45 10G ou 2,5G les gens font-ils réellement tourner dans la cage du NG, et lesquels sont connus pour ne pas lier ? Je préférerais acheter quelque chose qui est en service quelque part plutôt que de jouer aux dés trois fois.
Comments 4
Il n'existe pas de liste de compatibilité vendeur pour cette cage et il n'y en aura pas - le nombre de combinaisons de modules et de firmware rend ça impraticable à maintenir, donc ce qu'on a à la place ce sont des retours de propriétaires. D'après ce que les gens font tourner sur le NG : un SFP+ RJ-45 10Gtek du genre 1,25/2,5/5/10GBASE-T est celui qui monte le plus souvent, un module ipolex 10GBASE-T fonctionne, un MikroTik S+RJ10 fonctionne, et un SFP cuivre 2,5G Xicom bon marché a aussi été rapporté comme bon. Si le tronçon est assez court, les câbles DAC 10Gtek sont aussi dans la colonne « ça marche ». De l'autre côté du registre, un Solarflare SFM10G-TX a été rapporté comme ne fonctionnant pas.
Deux points pratiques. Achète chez un vendeur qui accepte les retours - le support hôte ici est étroit, donc tu risques de finir par changer de marque plutôt que de déboguer quoi que ce soit. Et attends-toi à ce qu'un module 10GBASE-T dans une coque SFP+ chauffe pas mal, ce qui compte si le routeur est dans un placard fermé.
À l'arrivée, vérifie
dmesg | grep -i sfpjuste après insertion et lisethtool -m eth2. Si le noyau n'identifie pas le module là, aucune configuration d'interface ne va le sauver.Ça vaut le coup de l'ajouter pour quiconque atterrit ici avec un Omnia classique plutôt que le NG. Sur ce boîtier, la cage n'achète aucune interface supplémentaire du tout. La cage et la prise WAN métallique sont toutes les deux derrière une seule MAC, eth2, et une seule d'entre elles y est câblée à un instant donné - laquelle dépend du blob device tree que le routeur charge au démarrage. Donc un module cuivre parfaitement sain a l'air complètement mort : rien de nouveau n'apparaît dans la liste des interfaces, et le WAN métallique perd même son adresse tant que le module reste inséré. Pointe /boot/dtb vers la variante SFP, redémarre, et le tableau change :
J'ai fait exactement ça sur TurrisOS 6.2.3 avec un module cuivre 2,5GBASE-T FS et le WAN est monté à 2,5 Gbit/s juste après le redémarrage. Je n'ai aucune idée si le NG a besoin de quelque chose de comparable, mais vérifie l'hôte avant de déclarer un module défectueux.
Merci, c'est la liste que je cherchais. Je commande le 10Gtek, et chez quelqu'un qui le reprend.
Une chose que j'aurais dû mettre dans la question, puisque le module officiel revient dans chacun de ces fils : j'avais effectivement le RTROM01-RTSF-10G dans cette cage auparavant. Ça a marché un moment, puis après environ un mois ça a commencé à jeter des erreurs de connexion, et j'ai abandonné et remis le lien sur un port ethernet classique. Donc l'option chère n'est pas automatiquement l'option sûre ici - c'est exactement pour ça que j'ai demandé des modules que les gens ont en service plutôt qu'une recommandation.
Un autre coin du même problème, même conclusion. Sur l'Omnia classique, le seul module dont je peux me porter garant est un TP-Link TL-SM321B - 1000Base-BX bidirectionnel, 1310 nm, LC. Le noyau le récupère sans aucune manœuvre et j'obtiens à peu près 920 Mbit/s de charge utile réelle dedans. Personne n'a besoin de partir à la chasse aux 80 Mbit/s manquants non plus : la ligne elle-même tourne à 1,25 Gbit/s, et entre l'encodage 8b10b et le framing Ethernet, c'est exactement là qu'atterrit le débit utilisable.
Contre-exemple avec le même routeur : un CTS SFP-31W2ASM10-DR fonctionnait bien sous Turris OS 3.x et est tombé mort une fois le boîtier passé en 4.0 - et le coupable là-bas était le modèle de configuration VLAN et switch remanié, pas le module. Et rappelle-toi d'où viennent les correctifs : le travail sur les SFP entre dans OpenWrt master bien avant d'apparaître dans la branche stable de Turris, donc quelque chose qui refuse de lier aujourd'hui peut discrètement revenir à la vie quelques releases plus tard.