Turris Omnia NG SFP+ kafesi: hangi üçüncü parti RJ-45 bakır modüller gerçekten link veriyor
Evde bir Turris Omnia NG çalıştırıyorum ve metalik WAN portunda oturan son şey, ISP router'ına iki metrelik bir bağlantı. O bağlantıyı SFP+ kafesine taşımak ve bakır portu lab tarafı için boşaltmak istiyorum. Resmi Turris SFP+ bakır modülü (RTROM01-RTSF-10G), küçük bir switch'in maliyeti kadar tutuyor ve ele geçirmesi de zaten zahmetli.
Kurulum:
- Turris Omnia NG, stok firmware, SFP+ kafesi şu anda boş
- ISP router'ına kısa bir RJ-45 hattı, o tarafta 1G
- eninde sonunda 1G'den daha hızlı ulaşmak istediğim, lab tarafında iki adet 10G host
- çekmecede test edecek yedek bakır SFP+ modülü yok
Geldiğinde bir modülü değerlendirmek için elimdeki her şey:
dmesg | grep -i sfp
ethtool -m eth2Şimdiye kadar yaptığım: kafes için resmi bir uyumluluk listesi aradım ve hiçbir şey bulamadım, bir satıcıya da gelmezse modülü geri alıp almadığını sordum.
Yani soru basit - insanlar NG kafesinde gerçekte hangi 10G veya 2.5G bakır RJ-45 modüllerini çalıştırıyor, hangilerinin link vermediği biliniyor? Üç kere zar atmaktansa bir yerde zaten hizmette olan bir şey almayı tercih ederim.
Comments 4
O kafes için bir vendor uyumluluk listesi yok ve olmayacak da - modül ve firmware kombinasyonlarının sayısı bunu sürdürmeyi pratik olmaktan çıkarıyor, yani onun yerine elinde sahip raporları oluyor. İnsanların NG'de çalıştırdıklarından: 1.25/2.5/5/10GBASE-T türünden bir 10Gtek RJ-45 SFP+ en sık gelen; bir ipolex 10GBASE-T modül çalışıyor, bir MikroTik S+RJ10 çalışıyor, ucuz bir Xicom 2.5G bakır SFP de sorunsuz olarak rapor edildi. Bağlantı yeterince kısaysa, 10Gtek DAC kabloları da çalışanlar sütununda. Defterin diğer tarafında, bir Solarflare SFM10G-TX'in çalışmadığı rapor edildi.
İki pratik nokta. İade kabul eden bir satıcıdan al - buradaki host desteği dar, yani bir şeyi debug etmek yerine markaları değiştirip durabilirsin. Bir de SFP+ kabuğundaki bir 10GBASE-T modülün sıcak çalışmasını bekle, bu router kapalı bir dolapta oturuyorsa önemli.
Geldiğinde, taktıktan hemen sonra
dmesg | grep -i sfpkontrol et veethtool -m eth2'yi oku. Kernel modülü orada tanımıyorsa, hiçbir interface konfigürasyonu onu kurtaramaz.NG yerine klasik bir Omnia ile buraya düşen olursa eklemekte fayda var. O kutuda kafes sana hiç ekstra bir interface kazandırmıyor. Kafes ve metalik WAN soketi, ikisi de tek bir MAC'in, eth2'nin arkasında oturuyor ve her an sadece biri ona bağlı - hangisinin bağlı olduğu router'ın boot'ta yüklediği device tree blob'a bağlı. Yani gayet sağlıklı bir bakır modül taş gibi ölü görünür: interface listesinde yeni bir şey çıkmaz, metalik WAN da modül takılı kaldığı sürece adresini bile düşürür. /boot/dtb'yi SFP varyantına yönlendir, reboot et, tablo değişir:
TurrisOS 6.2.3'te bir FS 2.5GBASE-T bakır modülle tam olarak bunu yaptım ve WAN, reboot'tan hemen sonra 2.5Gbps'de geldi. NG'nin buna benzer bir şeye ihtiyacı olup olmadığı hakkında hiçbir fikrim yok, ama bir modülü arızalı diye yazmadan önce host'u kontrol et.
Teşekkürler, peşinde olduğum liste tam olarak buydu. 10Gtek'i sipariş ediyorum, hem de geri alan bir yerden.
Soruya koymam gereken bir şey vardı, çünkü resmi modül bu thread'lerin her birinde çıkıyor: o kafeste daha önce RTROM01-RTSF-10G vardı. Bir süre çalıştı, sonra yaklaşık bir ay sonra bağlantı hataları vermeye başladı, ben de vazgeçip link'i normal bir ethernet portuna geri taşıdım. Yani pahalı seçenek burada otomatik olarak güvenli olan değil - tam da bu yüzden bir tavsiye değil, insanların hizmette tuttuğu modülleri sordum.
Aynı sorunun farklı bir köşesi, aynı sonuç. Klasik Omnia'da kefil olabileceğim tek modül bir TP-Link TL-SM321B - 1000Base-BX bidirectional, 1310 nm, LC. Kernel onu hiç zorlanmadan alıyor ve üzerinden yaklaşık 920 Mbit/s gerçek payload geçiriyorum. Kayıp 80 Mbit/s'in peşine düşmeye de kimsenin ihtiyacı yok: hattın kendisi 1.25 Gbit/s'de çalışıyor, 8b10b encoding ile Ethernet framing arasında kullanılabilir hız tam olarak orada oturuyor.
Aynı router'dan bir karşı örnek: bir CTS SFP-31W2ASM10-DR, Turris OS 3.x altında sorunsuz çalıştı ve kutu 4.0'a geçince öldü - ve oradaki suçlu, modül değil, yeniden çalışılmış VLAN ve switch konfigürasyon modeliydi. Bir de düzeltmelerin nereden geldiğini unutma: SFP çalışması, stable Turris branch'inde ortaya çıkmadan çok önce OpenWrt master'a giriyor, yani bugün link vermeyi reddeden bir şey birkaç release sonra sessizce canlanabilir.