Cage SFP+ do Turris Omnia NG: quais módulos de cobre RJ-45 de terceiros realmente linkam
Eu rodo um Turris Omnia NG em casa e a última coisa que fica na porta WAN metálica é um trecho de dois metros até o roteador da operadora. Eu gostaria de mover esse trecho para a cage SFP+ e liberar a porta de cobre para o lado do laboratório. O módulo de cobre SFP+ oficial da Turris (RTROM01-RTSF-10G) custa quase o mesmo que um switch pequeno e é difícil de encontrar.
Montagem:
- Turris Omnia NG, firmware de fábrica, cage SFP+ vazia no momento
- trecho curto RJ-45 até o roteador da operadora, 1G desse lado
- dois hosts 10G do lado do laboratório que eu eventualmente gostaria de alcançar mais rápido que 1G
- nenhum módulo de cobre SFP+ sobressalente na gaveta para testar
Tudo que tenho para julgar um módulo assim que ele chegar:
dmesg | grep -i sfp
ethtool -m eth2O que fiz até agora: procurei uma lista de compatibilidade oficial para a cage e não achei nada, e perguntei a um vendedor se eles aceitam devolução do módulo se ele não subir.
Então a pergunta é simples - quais módulos de cobre RJ-45 10G ou 2.5G as pessoas estão realmente rodando na cage do NG, e quais são conhecidos por não linkar? Eu prefiro comprar algo que está em serviço em algum lugar do que rolar o dado três vezes.
Comments 4
Não existe lista de compatibilidade do fabricante para essa cage e não vai existir - o número de combinações de módulo e firmware torna impraticável manter uma, então o que você tem em vez disso são relatos de donos. Pelo que as pessoas rodam no NG: um SFP+ RJ-45 10Gtek do tipo 1.25/2.5/5/10GBASE-T é o que sobe com mais frequência, um módulo ipolex 10GBASE-T funciona, um MikroTik S+RJ10 funciona, e um SFP de cobre 2.5G barato da Xicom também foi relatado como funcionando. Se o trecho for curto o suficiente, cabos DAC 10Gtek também entram na coluna dos que funcionam. Do outro lado da conta, um Solarflare SFM10G-TX foi relatado como não funcionando.
Dois pontos práticos. Compre de um vendedor que aceita devolução - o suporte do host aqui é estreito, então você pode acabar trocando de marca em vez de debugar qualquer coisa. E espere que um módulo 10GBASE-T num invólucro SFP+ esquente bastante, o que importa se o roteador fica num armário fechado.
Quando chegar, confira
dmesg | grep -i sfpimediatamente depois de inserir e leiaethtool -m eth2. Se o kernel não identificar o módulo ali, nenhuma quantidade de configuração de interface vai salvar isso.Vale acrescentar para quem cair aqui com um Omnia clássico em vez do NG. Nessa caixa a cage não te dá nenhuma interface extra. A cage e o soquete WAN metálico ficam os dois atrás de um único MAC, eth2, e só um deles fica ligado a ele a cada momento - qual dos dois depende do device tree blob que o roteador carrega no boot. Então um módulo de cobre perfeitamente saudável parece completamente morto: nada de novo aparece na lista de interfaces, e a WAN metálica até perde o endereço enquanto o módulo fica inserido. Aponte /boot/dtb para a variante SFP, reinicie, e o quadro muda:
Fiz exatamente isso no TurrisOS 6.2.3 com um módulo de cobre FS 2.5GBASE-T e a WAN subiu em 2.5Gbps logo depois do reboot. Não tenho ideia se o NG precisa de algo parecido, mas verifique o host antes de descartar um módulo como defeituoso.
Obrigado, essa é a lista que eu estava procurando. Vou pedir o 10Gtek, e de algum lugar que aceite devolução.
Uma coisa que eu deveria ter colocado na pergunta, já que o módulo oficial aparece em cada um desses tópicos: eu já tive o RTROM01-RTSF-10G naquela cage antes. Funcionou por um tempo, depois de mais ou menos um mês começou a jogar erros de conexão, e eu desisti e movi o link de volta para uma porta ethernet normal. Então a opção cara não é automaticamente a segura aqui - que é exatamente por isso que pedi módulos que as pessoas têm em serviço em vez de uma recomendação.
Um canto diferente do mesmo problema, mesma conclusão. No Omnia clássico o único módulo que eu posso confirmar é um TP-Link TL-SM321B - 1000Base-BX bidirecional, 1310 nm, LC. O kernel reconhece ele sem precisar de nenhuma insistência e eu consigo mais ou menos 920 Mbit/s de payload real através dele. Ninguém precisa sair caçando os 80 Mbit/s que faltam também: a linha em si roda a 1.25 Gbit/s, e entre a codificação 8b10b e o framing Ethernet é exatamente aí que a taxa utilizável cai.
Contraexemplo do mesmo roteador: um CTS SFP-31W2ASM10-DR rodava bem no Turris OS 3.x e morreu quando a caixa foi para o 4.0 - e o culpado ali foi o modelo reformulado de VLAN e configuração de switch, não o módulo. E lembre de onde vêm as correções: o trabalho de SFP vai para o master do OpenWrt bem antes de aparecer no branch estável da Turris, então algo que se recusa a linkar hoje pode silenciosamente ganhar vida um par de versões depois.