Turris Omnia NG SFP+-cage: welke RJ-45-kopermodules van derden linken daadwerkelijk
Ik draai thuis een Turris Omnia NG en het laatste wat nog op de metalen WAN-poort zit is een sprongetje van twee meter naar de router van de provider. Ik zou die verbinding graag naar de SFP+-cage verhuizen en de koperpoort vrijmaken voor de labkant. De officiële Turris SFP+-kopermodule (RTROM01-RTSF-10G) kost ongeveer wat een kleine switch kost en is sowieso lastig te bemachtigen.
Opstelling:
- Turris Omnia NG, standaardfirmware, SFP+-cage nu leeg
- korte RJ-45-verbinding naar de router van de provider, 1G aan die kant
- twee 10G-hosts aan de labkant die ik uiteindelijk sneller dan 1G zou willen bereiken
- geen kopermodules SFP+ in de la om mee te testen
Alles waarop ik een module kan beoordelen zodra hij binnenkomt:
dmesg | grep -i sfp
ethtool -m eth2Wat ik tot nu toe gedaan heb: gezocht naar een officiële compatibiliteitslijst voor de cage en niets gevonden, en aan een verkoper gevraagd of hij een module terugneemt als die niet opkomt.
De vraag is dus simpel: welke 10G- of 2.5G-kopermodules met RJ-45 draaien mensen daadwerkelijk in de NG-cage, en van welke is bekend dat ze niet linken? Ik koop liever iets dat ergens al in dienst is dan drie keer te dobbelen.
Comments 4
Voor die cage bestaat geen vendor-compatibiliteitslijst en die komt er ook niet: het aantal combinaties van module en firmware maakt onderhoud daarvan onhaalbaar, dus in plaats daarvan krijg je ervaringen van gebruikers. Wat mensen daadwerkelijk in de NG draaien: een 10Gtek RJ-45 SFP+ van het 1.25/2.5/5/10GBASE-T-type komt het vaakst op, een ipolex 10GBASE-T-module werkt, een MikroTik S+RJ10 werkt, en een goedkope Xicom 2.5G-kopermodule SFP is ook gemeld als prima werkend. Als de afstand kort genoeg is, staan 10Gtek DAC-kabels ook in de werkende kolom. Aan de andere kant van de streep: een Solarflare SFM10G-TX werd gemeld als niet-werkend.
Twee praktische punten. Koop bij een verkoper die retouren accepteert: de ondersteuning van de host is hier smal, dus je kunt eindigen met merken wisselen in plaats van iets te debuggen. En reken erop dat een 10GBASE-T-module in een SFP+-behuizing warm wordt, wat ertoe doet als de router in een gesloten kast staat.
Controleer bij aankomst meteen na het insteken
dmesg | grep -i sfpen leesethtool -m eth2. Identificeert de kernel de module daar niet, dan gaat geen enkele interfaceconfiguratie hem nog redden.Goed om toe te voegen voor iedereen die hier terechtkomt met een klassieke Omnia in plaats van de NG. Op die doos levert de cage helemaal geen extra interface op. De cage en de metalen WAN-aansluiting zitten allebei achter één MAC, eth2, en op elk moment is er maar één van de twee daadwerkelijk bekabeld ermee: welke, hangt af van de device tree blob die de router bij het opstarten laadt. Een kerngezonde kopermodule oogt dus stokdood: er verschijnt niets nieuws in de interfacelijst, en de metalen WAN verliest zelfs zijn adres zolang de module erin zit. Zet /boot/dtb op de SFP-variant, herstart, en het beeld verandert:
Precies dat gedaan op TurrisOS 6.2.3 met een FS 2.5GBASE-T-kopermodule en de WAN kwam meteen na de reboot op 2.5Gbps. Ik heb geen idee of de NG iets vergelijkbaars nodig heeft, maar controleer de host voordat je een module als defect afschrijft.
Bedankt, dat is de lijst waar ik naar op zoek was. Ik bestel de 10Gtek, en wel bij iemand die hem terugneemt.
Één ding had ik in de vraag moeten zetten, want de officiële module duikt in elk van deze topics op: ik heb de RTROM01-RTSF-10G eerder in die cage gehad. Hij werkte een tijdje, en na ongeveer een maand begon hij verbindingsfouten te geven, waarna ik het opgaf en de link terugzette naar een gewone ethernetpoort. De dure optie is hier dus niet automatisch de veilige keuze, en dat is precies waarom ik vroeg naar modules die mensen in dienst hebben in plaats van naar een aanbeveling.
Andere hoek van hetzelfde probleem, zelfde conclusie. Op de klassieke Omnia kan ik alleen voor een TP-Link TL-SM321B instaan: 1000Base-BX bidirectioneel, 1310 nm, LC. De kernel pikt hem op zonder gedoe en ik haal er zo'n 920 Mbit/s aan echte payload doorheen. Niemand hoeft op zoek naar de missende 80 Mbit/s: de lijn zelf draait op 1,25 Gbit/s, en tussen 8b10b-encoding en Ethernet-framing in is dat precies waar het bruikbare tempo landt.
Tegenvoorbeeld van dezelfde router: een CTS SFP-31W2ASM10-DR draaide prima onder Turris OS 3.x en ging dood zodra de doos naar 4.0 verhuisde: de boosdoener daar was het herziene VLAN- en switch-configuratiemodel, niet de module. En vergeet niet waar de fixes vandaan komen: SFP-werk gaat lang voordat het in de stabiele Turris-branch verschijnt al in OpenWrt master, dus iets dat vandaag weigert te linken kan een paar releases later stilletjes tot leven komen.