Cage SFP+ del Turris Omnia NG: quali moduli in rame RJ-45 di terze parti fanno davvero link
Faccio girare un Turris Omnia NG a casa e l'ultima cosa che sta sulla porta WAN metallica è una tratta di due metri verso il router dell'ISP. Vorrei spostare quella tratta nella cage SFP+ e liberare la porta in rame per il lato lab. Il modulo copper SFP+ ufficiale Turris (RTROM01-RTSF-10G) costa quanto uno switchetto e per di più è scomodo da procurarsi.
Configurazione:
- Turris Omnia NG, firmware stock, cage SFP+ attualmente vuota
- tratta RJ-45 corta verso il router dell'ISP, 1G su quel lato
- due host 10G sul lato lab che vorrei prima o poi raggiungere più veloce di 1G
- nessun modulo SFP+ in rame di scorta nel cassetto con cui testare
Tutto quello che ho per giudicare un modulo una volta arrivato:
dmesg | grep -i sfp
ethtool -m eth2Cosa ho fatto finora: cercato una lista di compatibilità ufficiale per la cage e non ho trovato niente, e chiesto a un venditore se riprende indietro un modulo se non sale.
Quindi la domanda è semplice: quali moduli in rame RJ-45 10G o 2.5G la gente fa girare davvero nella cage dell'NG, e quali sono noti per non fare link? Preferirei comprare qualcosa che è in servizio da qualche parte piuttosto che tirare i dadi tre volte.
Comments 4
Non c'è nessuna lista di compatibilità del vendor per quella cage e non ci sarà mai: il numero di combinazioni modulo-firmware la rende impraticabile da mantenere, quindi quello che ottieni al suo posto sono le segnalazioni dei proprietari. Da quello che la gente fa girare nell'NG: un RJ-45 SFP+ 10Gtek del tipo 1.25/2.5/5/10GBASE-T è quello che sale più spesso, un modulo ipolex 10GBASE-T funziona, un MikroTik S+RJ10 funziona, e anche un economico SFP in rame Xicom 2.5G è stato segnalato come funzionante. Se la tratta è abbastanza corta, anche i cavi DAC 10Gtek sono nella colonna dei funzionanti. Dall'altra parte del registro, un Solarflare SFM10G-TX è stato segnalato come non funzionante.
Due punti pratici. Compra da un venditore che accetta resi: il supporto host qui è ristretto, quindi potresti finire per cambiare marca piuttosto che debuggare qualcosa. E aspettati che un modulo 10GBASE-T in un guscio SFP+ scaldi parecchio, il che conta se il router sta in un armadietto chiuso.
Quando arriva, controlla
dmesg | grep -i sfpsubito dopo l'inserimento e leggiethtool -m eth2. Se il kernel lì non identifica il modulo, nessuna quantità di configurazione dell'interfaccia lo salverà.Vale la pena aggiungerlo per chiunque arrivi qui con un Omnia classico invece che l'NG. Su quella scatola la cage non ti compra nessuna interfaccia in più. La cage e il socket WAN metallico stanno entrambi dietro un unico MAC, eth2, e solo uno dei due è cablato a esso in un dato momento: quale dei due dipende dal device tree blob che il router carica al boot. Quindi un modulo in rame perfettamente sano sembra morto stecchito: non compare niente di nuovo nella lista delle interfacce, e il WAN metallico perde persino il suo indirizzo finché il modulo resta inserito. Punta /boot/dtb sulla variante SFP, riavvia, e il quadro cambia:
Ho fatto esattamente questo su TurrisOS 6.2.3 con un modulo in rame FS 2.5GBASE-T e il WAN è salito a 2,5Gbps subito dopo il reboot. Non ho idea se l'NG abbia bisogno di qualcosa di comparabile, ma controlla l'host prima di bollare un modulo come difettoso.
Grazie, è la lista che cercavo. Ordino il 10Gtek, e da un posto che lo riprende indietro.
Una cosa che avrei dovuto mettere nella domanda, visto che il modulo ufficiale spunta fuori in ognuno di questi thread: avevo avuto l'RTROM01-RTSF-10G in quella cage prima. Ha funzionato per un po', poi dopo circa un mese ha iniziato a lanciare errori di connessione, e ho rinunciato e riportato il link su una porta ethernet normale. Quindi l'opzione costosa non è automaticamente quella sicura qui, ed è esattamente per questo che ho chiesto moduli che la gente ha in servizio piuttosto che una raccomandazione.
Un altro angolo dello stesso problema, stessa conclusione. Sull'Omnia classico l'unico modulo per cui posso garantire è un TP-Link TL-SM321B: 1000Base-BX bidirezionale, 1310 nm, LC. Il kernel lo rileva senza bisogno di convincerlo e ottengo circa 920 Mbit/s di payload reale attraverso di esso. Non c'è nemmeno bisogno di andare a caccia degli 80 Mbit/s mancanti: la linea stessa gira a 1.25 Gbit/s, e tra la codifica 8b10b e il framing Ethernet è esattamente lì che atterra il rate utilizzabile.
Controesempio dallo stesso router: un CTS SFP-31W2ASM10-DR girava bene sotto Turris OS 3.x ed è morto una volta che la scatola è passata alla 4.0, e il colpevole lì era il modello di configurazione VLAN e switch rifatto, non il modulo. E ricorda da dove vengono le correzioni: il lavoro sugli SFP entra nel master di OpenWrt molto prima che una parte di esso spunti nel branch stabile di Turris, quindi qualcosa che si rifiuta di fare link oggi può silenziosamente tornare in vita un paio di release più tardi.