Cage SFP+ Turris Omnia NG: modul copper RJ-45 third-party mana yang benar-benar bisa link
Saya menjalankan Turris Omnia NG di rumah dan hal terakhir yang masih duduk di port WAN metallic itu hop dua meter ke router ISP. Saya ingin memindahkan hop itu ke cage SFP+ dan membebaskan port copper-nya untuk sisi lab. Modul copper SFP+ resmi Turris (RTROM01-RTSF-10G) harganya kira-kira sama dengan switch kecil dan cukup susah didapatkan sama sekali.
Setup:
- Turris Omnia NG, firmware stock, cage SFP+ sekarang kosong
- run RJ-45 pendek ke router ISP, 1G di sisi itu
- dua host 10G di sisi lab yang akhirnya ingin saya jangkau lebih cepat dari 1G
- tidak ada modul copper SFP+ cadangan di laci untuk testing
Semua yang saya punya untuk menilai modul begitu datang:
dmesg | grep -i sfp
ethtool -m eth2Yang sudah saya lakukan sejauh ini: cari compatibility list resmi untuk cage-nya dan tidak menemukan apa-apa, dan tanya satu seller apakah mereka menerima modul kembali kalau tidak bisa up.
Jadi pertanyaannya sederhana - modul copper RJ-45 10G atau 2.5G mana yang benar-benar dijalankan orang di cage NG, dan mana yang diketahui tidak mau link? Saya lebih suka beli sesuatu yang sudah in service di suatu tempat daripada judi tiga kali.
Comments 4
Tidak ada compatibility list resmi dari vendor untuk cage itu dan tidak akan pernah ada - jumlah kombinasi modul dan firmware-nya membuat itu tidak praktis untuk dipelihara, jadi yang kamu dapat sebagai gantinya adalah laporan pemilik. Dari yang dijalankan orang di NG: SFP+ RJ-45 10Gtek jenis 1.25/2.5/5/10GBASE-T itu yang paling sering berhasil up, modul 10GBASE-T ipolex jalan, MikroTik S+RJ10 jalan, dan SFP copper 2.5G Xicom yang murah juga dilaporkan baik-baik saja. Kalau hop-nya cukup pendek, kabel DAC 10Gtek juga masuk kolom yang berhasil. Di sisi lain neraca, Solarflare SFM10G-TX dilaporkan tidak jalan.
Dua poin praktis. Beli dari seller yang menerima retur - dukungan host di sini sempit, jadi kamu mungkin berakhir menukar merek daripada men-debug apa pun. Dan siap-siap modul 10GBASE-T dalam shell SFP+ itu panas, yang penting kalau router-nya duduk di lemari tertutup.
Waktu datang, cek
dmesg | grep -i sfpsegera setelah dipasang dan bacaethtool -m eth2. Kalau kernel-nya tidak mengidentifikasi modulnya di situ, konfigurasi interface sebanyak apa pun tidak akan menyelamatkannya.Layak ditambahkan buat siapa pun yang mendarat di sini dengan Omnia classic, bukan NG. Di box itu cage-nya sama sekali tidak memberi interface tambahan. Cage dan soket WAN metallic-nya sama-sama duduk di belakang satu MAC, eth2, dan cuma satu dari keduanya yang terhubung ke situ di momen tertentu - yang mana tergantung device tree blob yang di-load router-nya waktu boot. Jadi modul copper yang benar-benar sehat kelihatan mati total: tidak ada yang baru muncul di interface list, dan WAN metallic-nya bahkan kehilangan alamatnya selama modulnya masih terpasang. Arahkan /boot/dtb ke varian SFP, reboot, dan gambarannya berubah:
Saya lakukan persis itu di TurrisOS 6.2.3 dengan modul copper 2.5GBASE-T FS dan WAN-nya naik di 2.5Gbps langsung setelah reboot. Saya tidak tahu apa NG butuh sesuatu yang sebanding, tapi cek dulu host-nya sebelum kamu mencoret modul sebagai rusak.
Terima kasih, itu list yang saya cari. Pesan yang 10Gtek, dan dari tempat yang menerima retur.
Satu hal yang seharusnya saya masukkan ke pertanyaan, karena modul resminya selalu muncul di tiap thread seperti ini: saya sebenarnya pernah punya RTROM01-RTSF-10G di cage itu sebelumnya. Jalan beberapa waktu, lalu setelah sekitar sebulan mulai melempar connection error, dan saya menyerah dan memindahkan link-nya kembali ke port ethernet biasa. Jadi opsi yang mahal tidak otomatis jadi yang aman di sini - itu persis kenapa saya minta modul yang benar-benar in service pada orang, bukan rekomendasi.
Sudut yang berbeda dari masalah yang sama, kesimpulan yang sama. Di Omnia classic, satu-satunya modul yang bisa saya jamin itu TP-Link TL-SM321B - 1000Base-BX bidirectional, 1310 nm, LC. Kernel-nya langsung mengenalinya tanpa dibujuk-bujuk dan saya dapat sekitar 920 Mbit/s payload asli lewat situ. Tidak perlu juga repot mencari 80 Mbit/s yang hilang: jalurnya sendiri berjalan di 1.25 Gbit/s, dan di antara 8b10b encoding dan Ethernet framing itu persis di mana usable rate-nya mendarat.
Contoh sebaliknya dari router yang sama: CTS SFP-31W2ASM10-DR jalan baik di Turris OS 3.x dan mati begitu box-nya pindah ke 4.0 - dan biang keladinya di situ adalah model konfigurasi VLAN dan switch yang dirombak ulang, bukan modulnya. Dan ingat dari mana fix-nya datang: pekerjaan SFP masuk ke OpenWrt master jauh sebelum semuanya muncul di branch Turris yang stable, jadi sesuatu yang menolak link hari ini bisa diam-diam hidup lagi beberapa release kemudian.