Jaula SFP+ de una Turris Omnia NG: qué módulos de cobre RJ-45 de terceros realmente enlazan
Tengo una Turris Omnia NG en casa y lo último que queda en el puerto WAN metálico es un tramo de dos metros hasta el router del ISP. Me gustaría mover ese tramo a la jaula SFP+ y liberar el puerto de cobre para el lado del laboratorio. El módulo de cobre SFP+ oficial de Turris (RTROM01-RTSF-10G) cuesta aproximadamente lo que cuesta un switch pequeño y es bastante difícil de conseguir.
Montaje:
- Turris Omnia NG, firmware de fábrica, jaula SFP+ actualmente vacía
- tramo corto RJ-45 hasta el router del ISP, 1G de ese lado
- dos hosts de 10G del lado del laboratorio a los que eventualmente me gustaría llegar más rápido que a 1G
- ningún módulo de cobre SFP+ de repuesto en el cajón para probar
Todo lo que tengo para juzgar un módulo cuando llegue:
dmesg | grep -i sfp
ethtool -m eth2Lo que hice hasta ahora: busqué una lista oficial de compatibilidad para la jaula y no encontré nada, y le pregunté a un vendedor si aceptan devolución si el módulo no sube.
Así que la pregunta es simple: ¿qué módulos de cobre RJ-45 de 10G o 2,5G está usando realmente la gente en la jaula de la NG, y cuáles se sabe que no enlazan? Preferiría comprar algo que ya esté en servicio en alguna parte antes que tirar los dados tres veces.
Comments 4
No existe una lista de compatibilidad del fabricante para esa jaula y no va a haberla: el número de combinaciones de módulo y firmware hace que mantenerla sea poco práctico, así que lo que se obtiene en su lugar son informes de propietarios. De lo que la gente usa en la NG: un SFP+ RJ-45 de 10Gtek del tipo 1,25/2,5/5/10GBASE-T es el que sube con más frecuencia, un módulo 10GBASE-T de ipolex funciona, un S+RJ10 de MikroTik funciona, y también se reportó que un SFP de cobre 2,5G barato de Xicom va bien. Si el tramo es lo bastante corto, los cables DAC de 10Gtek también están en la columna de los que funcionan. Del otro lado de la balanza, se reportó que un Solarflare SFM10G-TX no funciona.
Dos puntos prácticos. Compra a un vendedor que acepte devoluciones; el soporte del host aquí es limitado, así que puede que termines cambiando de marca en vez de depurar nada. Y espera que un módulo 10GBASE-T dentro de una carcasa SFP+ se caliente, lo cual importa si el router está en un armario cerrado.
Cuando llegue, revisa
dmesg | grep -i sfpinmediatamente después de insertarlo y leeethtool -m eth2. Si el kernel no identifica el módulo ahí, ninguna configuración de interfaz va a rescatarlo.Vale la pena añadir esto para quien llegue aquí con una Omnia clásica en vez de la NG. En esa caja la jaula no da ninguna interfaz adicional. La jaula y el zócalo WAN metálico están ambos detrás de una sola MAC, eth2, y solo uno de ellos está cableado a ella en un momento dado, lo cual depende del blob de device tree que el router carga al arrancar. Así que un módulo de cobre perfectamente sano se ve muerto como una piedra: nada nuevo aparece en la lista de interfaces, e incluso el WAN metálico pierde su dirección mientras el módulo se queda puesto. Apunta /boot/dtb a la variante SFP, reinicia, y el panorama cambia:
Hice exactamente eso en TurrisOS 6.2.3 con un módulo de cobre 2,5GBASE-T de FS y el WAN subió a 2,5Gbps justo después del reinicio. No tengo idea de si la NG necesita algo comparable, pero revisa el host antes de dar un módulo por defectuoso.
Gracias, esa es la lista que buscaba. Voy a pedir el 10Gtek, y de algún sitio que lo acepte de vuelta.
Una cosa que debí haber puesto en la pregunta, ya que el módulo oficial aparece en todos estos hilos: sí tuve el RTROM01-RTSF-10G en esa jaula antes. Funcionó un tiempo, luego después de un mes más o menos empezó a dar errores de conexión, y desistí y moví el enlace de vuelta a un puerto ethernet normal. Así que la opción cara no es automáticamente la segura aquí, que es exactamente por qué pedí módulos que la gente tenga en servicio en vez de una recomendación.
Otro rincón del mismo problema, misma conclusión. En la Omnia clásica el único módulo por el que puedo responder es un TP-Link TL-SM321B, 1000Base-BX bidireccional, 1310 nm, LC. El kernel lo reconoce sin ningún truco y obtengo aproximadamente 920 Mbit/s de payload real a través de él. Tampoco hace falta salir a buscar los 80 Mbit/s que faltan: la línea en sí corre a 1,25 Gbit/s, y entre la codificación 8b10b y el framing de Ethernet, ahí es exactamente donde cae la tasa utilizable.
Contraejemplo del mismo router: un CTS SFP-31W2ASM10-DR funcionaba bien bajo Turris OS 3.x y quedó muerto en cuanto la caja pasó a 4.0, y el culpable ahí fue el modelo de configuración rediseñado de VLAN y switch, no el módulo. Y recuerda de dónde vienen los arreglos: el trabajo de SFP entra en OpenWrt master mucho antes de que aparezca en la rama estable de Turris, así que algo que hoy se niega a enlazar puede volver a la vida en silencio un par de versiones después.