Cage SFP+ trên Turris Omnia NG: module đồng RJ-45 bên thứ ba nào thực sự lên link
Mình chạy một Turris Omnia NG ở nhà, thứ cuối cùng còn nằm trên cổng WAN đồng là một đoạn hai mét đến router của ISP. Mình muốn chuyển đoạn đó sang cage SFP+ để giải phóng cổng đồng cho phía lab. Module đồng SFP+ chính hãng Turris (RTROM01-RTSF-10G) giá ngang một switch nhỏ và cũng khó kiếm.
Cấu hình:
- Turris Omnia NG, firmware gốc, cage SFP+ hiện đang trống
- đoạn RJ-45 ngắn đến router ISP, phía đó chạy 1G
- hai host 10G phía lab mà cuối cùng mình muốn kết nối nhanh hơn 1G
- không có sẵn module đồng SFP+ dự phòng trong ngăn kéo để test
Mọi thứ mình có để đánh giá một module khi nó về tới nơi:
dmesg | grep -i sfp
ethtool -m eth2Đã làm gì rồi: tìm danh sách tương thích chính thức cho cage đó và không thấy gì cả, và hỏi một người bán xem có nhận lại module nếu nó không lên link không.
Vậy câu hỏi đơn giản thôi - module đồng RJ-45 10G hay 2.5G nào người ta thực sự đang chạy trong cage của NG, và loại nào đã biết là không lên link? Mình thà mua thứ đang chạy thật ở đâu đó còn hơn tung xúc xắc ba lần.
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Không có danh sách tương thích từ vendor cho cage đó và cũng sẽ không có - số lượng tổ hợp module và firmware nhiều đến mức duy trì danh sách là bất khả thi, nên thứ bạn có thay vào đó là báo cáo từ người dùng thật. Từ những gì người ta chạy trên NG: một SFP+ RJ-45 10Gtek loại 1.25/2.5/5/10GBASE-T là loại lên link nhiều nhất, một module 10GBASE-T của ipolex chạy được, MikroTik S+RJ10 chạy được, và một SFP đồng 2.5G giá rẻ của Xicom cũng được báo là ổn. Nếu đoạn kết nối đủ ngắn thì DAC 10Gtek cũng nằm trong cột chạy được. Ở phía bên kia sổ sách, một Solarflare SFM10G-TX được báo là không chạy.
Hai điểm thực tế. Mua từ người bán chấp nhận đổi trả - hỗ trợ từ host ở đây khá hẹp, nên rốt cuộc bạn có thể phải đổi hãng thay vì debug được gì. Và cứ chuẩn bị tinh thần là module 10GBASE-T nhồi trong vỏ SFP+ sẽ chạy khá nóng, điều này quan trọng nếu router nằm trong tủ kín.
Khi hàng về, kiểm tra
dmesg | grep -i sfpngay sau khi cắm vào và đọcethtool -m eth2. Nếu kernel không nhận diện được module ở đó thì có cấu hình interface kiểu gì cũng không cứu được.Đáng bổ sung cho ai lạc vào đây với một Omnia classic thay vì NG. Trên máy đó, cage không mang lại thêm interface nào cả. Cage và cổng WAN đồng đều nằm sau cùng một MAC, eth2, và chỉ một trong hai được nối vào nó tại bất kỳ thời điểm nào - cái nào thì tùy vào device tree blob mà router load lúc boot. Nên một module đồng hoàn toàn khỏe mạnh lại trông như chết cứng: chẳng có gì mới xuất hiện trong danh sách interface, và WAN đồng thậm chí còn mất địa chỉ suốt thời gian module còn cắm trong đó. Trỏ /boot/dtb sang biến thể SFP, reboot, và bức tranh đổi khác:
Mình làm đúng vậy trên TurrisOS 6.2.3 với một module đồng FS 2.5GBASE-T và WAN lên ở 2.5Gbps ngay sau khi reboot. Mình không biết NG có cần thứ gì tương tự không, nhưng cứ kiểm tra host trước khi kết tội một module là hỏng.
Cảm ơn, đúng là danh sách mình cần. Đặt hàng con 10Gtek, từ chỗ nhận đổi trả.
Có một điều lẽ ra mình nên đưa vào câu hỏi, vì module chính hãng cứ xuất hiện trong mọi thread kiểu này: mình từng có RTROM01-RTSF-10G trong cage đó trước rồi. Nó chạy được một thời gian, rồi sau khoảng một tháng bắt đầu báo lỗi kết nối, và mình bỏ cuộc, chuyển link về lại cổng ethernet thường. Vậy nên lựa chọn đắt tiền ở đây không tự động là lựa chọn an toàn - đó chính xác là lý do mình hỏi module người ta đang chạy thật chứ không phải xin một khuyến nghị.
Một góc khác của cùng vấn đề, cùng kết luận. Trên Omnia classic, module duy nhất mình dám bảo đảm là TP-Link TL-SM321B - 1000Base-BX hai chiều, 1310 nm, LC. Kernel nhận nó mà không cần dỗ dành gì cả, và mình được khoảng 920 Mbit/s payload thật qua nó. Cũng chẳng ai cần đi tìm 80 Mbit/s bị thiếu đâu: bản thân đường truyền chạy ở 1.25 Gbit/s, và giữa mã hóa 8b10b với framing Ethernet thì đó đúng là chỗ tốc độ khả dụng rơi vào.
Ví dụ ngược từ cùng con router: một CTS SFP-31W2ASM10-DR chạy tốt dưới Turris OS 3.x rồi chết hẳn khi máy chuyển lên 4.0 - và thủ phạm ở đó là mô hình cấu hình VLAN và switch bị viết lại, không phải module. Và nhớ là các bản fix đến từ đâu: công sức về SFP vào OpenWrt master trước rất lâu so với lúc nó xuất hiện ở nhánh Turris ổn định, nên thứ hôm nay từ chối lên link có thể lặng lẽ sống lại vài bản release sau.