Turris Omnia NG SFP+-Cage: welche RJ-45-Kupfermodule von Drittanbietern wirklich Link bekommen
Ich betreibe zu Hause einen Turris Omnia NG, und das Letzte, was noch am metallischen WAN-Port hängt, ist eine zwei Meter kurze Strecke zum Router des ISP. Die würde ich gern in die SFP+-Cage verlegen und den Kupfer-Port für die Laborseite freimachen. Das offizielle Turris-SFP+-Kupfermodul (RTROM01-RTSF-10G) kostet etwa so viel wie ein kleiner Switch und ist kaum zu bekommen.
Setup:
- Turris Omnia NG, Werksfirmware, SFP+-Cage aktuell leer
- kurze RJ-45-Strecke zum Router des ISP, dort 1G
- zwei 10G-Hosts auf der Laborseite, die ich irgendwann schneller als mit 1G erreichen möchte
- keine Kupfer-SFP+-Module in der Schublade zum Testen
Alles, womit ich ein Modul beurteilen kann, sobald es ankommt:
dmesg | grep -i sfp
ethtool -m eth2Was ich bisher gemacht habe: nach einer offiziellen Kompatibilitätsliste für die Cage gesucht und nichts gefunden, und einen Verkäufer gefragt, ob er ein Modul zurücknimmt, wenn es nicht hochkommt.
Die Frage ist also einfach: Welche 10G- oder 2.5G-RJ-45-Kupfermodule laufen bei anderen tatsächlich in der NG-Cage, und welche sind bekannt dafür, keinen Link zu bekommen? Lieber kaufe ich etwas, das irgendwo schon im Einsatz ist, als dreimal zu würfeln.
Comments 4
Für diese Cage gibt es keine Kompatibilitätsliste vom Hersteller, und es wird auch keine geben: Die Zahl der Modul- und Firmware-Kombinationen macht das unpraktikabel zu pflegen, also bleiben nur Erfahrungsberichte von Besitzern. Was Leute tatsächlich in der NG laufen haben: Ein 10Gtek-RJ-45-SFP+ der 1.25/2.5/5/10GBASE-T-Sorte kommt am häufigsten hoch, ein ipolex-10GBASE-T-Modul funktioniert, ein MikroTik S+RJ10 funktioniert, und auch ein billiger Xicom-2.5G-Kupfer-SFP wurde als funktionierend gemeldet. Wenn die Strecke kurz genug ist, gehören auch 10Gtek-DAC-Kabel in die funktionierende Spalte. Auf der anderen Seite: Ein Solarflare SFM10G-TX wurde als nicht funktionierend gemeldet.
Zwei praktische Punkte. Bei einem Verkäufer kaufen, der Rücknahmen akzeptiert: Der Support hier ist dünn, es kann also sein, dass am Ende Marken getauscht statt irgendetwas debuggt wird. Und ein 10GBASE-T-Modul im SFP+-Gehäuse wird heiß, was zählt, wenn der Router in einem geschlossenen Schrank steht.
Sobald es ankommt: direkt nach dem Einstecken
dmesg | grep -i sfpprüfen undethtool -m eth2lesen. Wenn der Kernel das Modul dort nicht erkennt, rettet keine noch so ausführliche Interface-Konfiguration mehr etwas.Nachtrag für alle, die hier mit dem klassischen Omnia statt dem NG landen. Auf dieser Box bringt die Cage überhaupt kein zusätzliches Interface. Die Cage und die metallische WAN-Buchse hängen beide an derselben MAC, eth2, und zu jedem Zeitpunkt ist nur eine von beiden tatsächlich verdrahtet: welche, hängt vom Device-Tree-Blob ab, den der Router beim Boot lädt. Ein völlig gesundes Kupfermodul sieht dadurch mausetot aus: In der Interface-Liste taucht nichts Neues auf, und die metallische WAN-Buchse verliert sogar ihre Adresse, solange das Modul steckt. /boot/dtb auf die SFP-Variante zeigen lassen, neu starten, und das Bild ändert sich:
Genau das auf TurrisOS 6.2.3 mit einem FS-2.5GBASE-T-Kupfermodul gemacht, und der WAN kam direkt nach dem Neustart mit 2.5Gbps hoch. Keine Ahnung, ob der NG etwas Vergleichbares braucht, aber erst den Host prüfen, bevor ein Modul als defekt abgeschrieben wird.
Danke, genau die Liste, die ich gesucht habe. Bestelle das 10Gtek, und zwar bei jemandem, der es zurücknimmt.
Eine Sache, die ich schon in die Frage hätte schreiben sollen, weil das offizielle Modul in jedem dieser Threads auftaucht: Ich hatte das RTROM01-RTSF-10G vorher schon in dieser Cage. Es lief eine Weile, dann fing es nach etwa einem Monat an, Verbindungsfehler zu werfen, und ich habe aufgegeben und den Link zurück auf einen normalen Ethernet-Port gelegt. Die teure Option ist hier also nicht automatisch die sichere: genau deshalb habe ich nach Modulen gefragt, die bei anderen im Einsatz sind, und nicht nach einer Empfehlung.
Anderer Winkel desselben Problems, gleiches Fazit. Am klassischen Omnia ist das einzige Modul, für das ich die Hand ins Feuer lege, ein TP-Link TL-SM321B: 1000Base-BX bidirektional, 1310 nm, LC. Der Kernel nimmt es ohne jedes Zureden an, und ich bekomme rund 920 Mbit/s Nutzlast durch. Die fehlenden 80 Mbit/s muss auch niemand suchen: Die Leitung selbst läuft mit 1,25 Gbit/s, und zwischen 8b10b-Codierung und Ethernet-Framing landet die nutzbare Rate genau dort.
Gegenbeispiel vom selben Router: Ein CTS SFP-31W2ASM10-DR lief unter Turris OS 3.x problemlos und war tot, sobald die Box auf 4.0 umzog: Der Schuldige dort war das überarbeitete VLAN- und Switch-Konfigurationsmodell, nicht das Modul. Und dran denken, woher die Fixes kommen: SFP-Arbeit landet im OpenWrt-Master lange bevor irgendetwas davon im stabilen Turris-Branch ankommt, was heute keinen Link bekommt, kann also ein paar Releases später still und leise doch noch anspringen.