Klatka SFP+ w Turris Omnia NG: które moduły miedziane RJ-45 firm trzecich faktycznie linkują
W domu mam Turris Omnia NG, i ostatnią rzeczą siedzącą na metalicznym porcie WAN jest dwumetrowy odcinek do routera ISP. Chciałbym przenieść ten odcinek do klatki SFP+ i zwolnić port miedziany dla strony laboratoryjnej. Oficjalny moduł miedziany SFP+ Turris (RTROM01-RTSF-10G) kosztuje mniej więcej tyle, co mały switch, i w ogóle trudno go zdobyć.
Setup:
- Turris Omnia NG, fabryczny firmware, klatka SFP+ obecnie pusta
- krótki odcinek RJ-45 do routera ISP, po tej stronie 1G
- dwa hosty 10G po stronie laboratoryjnej, do których docelowo chciałbym mieć szybciej niż 1G
- brak zapasowych miedzianych modułów SFP+ w szufladzie do testów
Wszystko, po czym mogę ocenić moduł, gdy już dotrze:
dmesg | grep -i sfp
ethtool -m eth2Co już zrobiłem: szukałem oficjalnej listy kompatybilności dla tej klatki i nic nie znalazłem, i zapytałem jednego sprzedawcę, czy przyjmie moduł z powrotem, jeśli nie wstanie.
Więc pytanie jest proste - jakie moduły miedziane RJ-45 10G albo 2.5G ludzie faktycznie mają uruchomione w klatce NG, a o jakich wiadomo, że nie linkują? Wolałbym kupić coś, co gdzieś już działa, niż rzucać kością trzy razy.
Comments 4
Dla tej klatki nie ma listy kompatybilności od vendora i nie będzie - liczba kombinacji modułów i firmware'u czyni jej utrzymywanie niepraktycznym, więc zamiast tego dostajesz relacje właścicieli. Z tego, co ludzie mają uruchomione w NG: 10Gtek RJ-45 SFP+ typu 1.25/2.5/5/10GBASE-T to ten, który wstaje najczęściej, działa moduł ipolex 10GBASE-T, działa MikroTik S+RJ10, i tani miedziany SFP 2.5G od Xicom też był zgłaszany jako działający. Jeśli odcinek jest wystarczająco krótki, w kolumnie działających są też kable DAC 10Gtek. Po drugiej stronie bilansu: Solarflare SFM10G-TX był zgłaszany jako niedziałający.
Dwie praktyczne uwagi. Kupuj od sprzedawcy, który przyjmuje zwroty - wsparcie po stronie hosta jest tu wąskie, więc możesz skończyć na zamianie marek zamiast na debugowaniu czegokolwiek. I spodziewaj się, że moduł 10GBASE-T w obudowie SFP+ będzie się mocno grzał, co ma znaczenie, jeśli router siedzi w zamkniętej szafce.
Kiedy dotrze, sprawdź
dmesg | grep -i sfpzaraz po włożeniu i przeczytajethtool -m eth2. Jeśli jądro tam nie zidentyfikuje modułu, żadna ilość konfigurowania interfejsu tego nie uratuje.Warto dodać dla każdego, kto tu trafi z klasyczną Omnią zamiast NG. Na tym urządzeniu klatka w ogóle nie daje dodatkowego interfejsu. Klatka i metaliczne gniazdo WAN obie siedzą za jednym MAC-iem, eth2, i w danej chwili tylko jedna z nich jest do niego podłączona - która, zależy od device tree blob, który router ładuje przy starcie. Więc całkowicie sprawny moduł miedziany wygląda jak kompletnie martwy: na liście interfejsów nic nowego się nie pojawia, a metaliczny WAN nawet traci swój adres na cały czas, kiedy moduł tam siedzi. Skieruj /boot/dtb na wariant SFP, zrestartuj, i obraz się zmienia:
Zrobiłem dokładnie to na TurrisOS 6.2.3 z miedzianym modułem FS 2.5GBASE-T i WAN wstał na 2.5Gbps zaraz po restarcie. Nie mam pojęcia, czy NG potrzebuje czegoś podobnego, ale sprawdź hosta, zanim spiszesz moduł na straty jako wadliwy.
Dzięki, o taką listę mi chodziło. Zamawiam 10Gtek, i to od kogoś, kto przyjmuje zwroty.
Jedna rzecz, którą powinienem był ująć w pytaniu, skoro oficjalny moduł wraca w każdym takim wątku: wcześniej miałem RTROM01-RTSF-10G w tej klatce. Działał przez jakiś czas, potem po jakimś miesiącu zaczął sypać błędami połączenia, i dałem sobie spokój, przenosząc link z powrotem na zwykły port ethernet. Więc droższa opcja nie jest tu automatycznie tą bezpieczną - dokładnie dlatego pytałem o moduły, które ludzie mają w eksploatacji, a nie o rekomendację.
Inny kąt tego samego problemu, ten sam wniosek. Na klasycznej Omni jedynym modułem, za który mogę ręczyć, jest TP-Link TL-SM321B - 1000Base-BX bidirectional, 1310 nm, LC. Jądro podłapuje go bez żadnego przekonywania i dostaję przez niego jakieś 920 Mbit/s realnego payloadu. Nikomu nie trzeba też szukać brakujących 80 Mbit/s: sama linia pracuje na 1,25 Gbit/s, i między kodowaniem 8b10b a ramkowaniem Ethernet to dokładnie tam ląduje użyteczna przepustowość.
Kontrprzykład z tego samego routera: CTS SFP-31W2ASM10-DR działał dobrze pod Turris OS 3.x i padł, gdy urządzenie przeszło na 4.0 - a winowajcą był tam przebudowany model konfiguracji VLAN i switcha, nie moduł. I pamiętaj, skąd biorą się poprawki: praca nad SFP trafia do OpenWrt master długo zanim cokolwiek z tego pojawi się w stabilnej gałęzi Turris, więc coś, co dziś odmawia linkowania, może cicho ożyć parę wydań później.