Turris Omnia NG के SFP+ cage में third-party RJ-45 copper modules में से असल में कौन से link करते हैं
घर पर एक Turris Omnia NG चलाता हूं और metallic WAN port पर बैठी आखिरी चीज़ ISP router तक का दो मीटर वाला hop है। मैं उस hop को SFP+ cage में ले जाना चाहता हूं और copper port को lab side के लिए खाली करना चाहता हूं। official Turris SFP+ copper module (RTROM01-RTSF-10G) कीमत में लगभग एक छोटे switch जितना पड़ता है और हाथ लगाना भी मुश्किल है।
Setup:
- Turris Omnia NG, stock firmware, SFP+ cage अभी खाली
- ISP router तक छोटा RJ-45 run, उस तरफ 1G
- lab side पर दो 10G hosts जिन्हें मैं आगे चलकर 1G से तेज़ पहुंचना चाहूंगा
- test करने के लिए दराज में कोई spare copper SFP+ module नहीं
module आने के बाद उसे परखने के लिए मेरे पास बस यही है:
dmesg | grep -i sfp
ethtool -m eth2अब तक जो किया: cage के लिए कोई official compatibility list ढूंढी और कुछ नहीं मिला, और एक seller से पूछा कि अगर module up न हो तो क्या वो वापस लेते हैं।
तो सवाल सीधा है - NG cage में लोग असल में कौन से 10G या 2.5G copper RJ-45 modules चला रहे हैं, और कौन से जाने-माने तौर पर link नहीं करते? तीन बार पासा फेंकने से बेहतर है कि कहीं already service में चल रही कोई चीज़ खरीद लूं।
Comments 4
उस cage के लिए कोई vendor compatibility list है ही नहीं और बनेगी भी नहीं - module और firmware combinations की गिनती इतनी है कि उसे maintain करना practical नहीं है, तो इसके बदले owners की reports ही मिलती हैं। लोग NG में जो चलाते हैं उसमें से: 1.25/2.5/5/10GBASE-T टाइप का 10Gtek RJ-45 SFP+ सबसे ज्यादा बार चल जाता है, एक ipolex 10GBASE-T module काम करता है, MikroTik S+RJ10 काम करता है, और एक सस्ता Xicom 2.5G copper SFP भी ठीक रिपोर्ट हुआ है। अगर hop इतना छोटा है, तो 10Gtek DAC cables भी काम करने वालों में शामिल हैं। दूसरी तरफ, एक Solarflare SFM10G-TX काम न करने की रिपोर्ट हुआ है।
दो practical बातें। ऐसे seller से खरीदो जो return लेता हो - यहां host support बहुत सीमित है, तो हो सकता है डिबग करने की बजाय brand ही बदलनी पड़ें। और उम्मीद रखो कि SFP+ shell में 10GBASE-T module गर्म चलेगा, जो मायने रखता है अगर router किसी बंद कैबिनेट में बैठा है।
module आने पर, डालते ही तुरंत
dmesg | grep -i sfpचेक करो औरethtool -m eth2पढ़ो। अगर kernel वहां module को पहचानता ही नहीं, तो interface configuration की कितनी भी कोशिश उसे नहीं बचाएगी।जो कोई भी यहां NG की बजाय classic Omnia के साथ आए, उसके लिए यह जोड़ना ज़रूरी है। उस box पर cage कोई extra interface देता ही नहीं। cage और metallic WAN socket दोनों एक ही MAC, eth2, के पीछे बैठे हैं, और किसी भी पल इनमें से सिर्फ एक ही उससे wired होता है - कौन सा, यह इस पर depend करता है कि router boot पर कौन सा device tree blob load करता है। तो एक बिल्कुल ठीक copper module भी बिल्कुल मरा हुआ लगता है: interface list में कुछ नया आता ही नहीं, और metallic WAN तो module अंदर रहने भर तक अपना address भी छोड़ देता है। /boot/dtb को SFP variant पर point करो, reboot करो, और तस्वीर बदल जाती है:
मैंने TurrisOS 6.2.3 पर एक FS 2.5GBASE-T copper module के साथ ठीक यही किया और reboot के तुरंत बाद WAN 2.5Gbps पर up हो गया। मुझे नहीं पता कि NG को भी ऐसा कुछ चाहिए या नहीं, पर किसी module को faulty मानने से पहले host चेक कर लो।
शुक्रिया, यही list चाहिए थी। 10Gtek order कर रहा हूं, वहां से जो इसे वापस लेता है।
एक बात मुझे सवाल में ही डाल देनी चाहिए थी, क्योंकि official module हर ऐसी thread में आ ही जाता है: उस cage में पहले RTROM01-RTSF-10G था ही। कुछ समय काम किया, फिर करीब एक महीने बाद connection errors देने लगा, और मैंने हार मानकर link वापस एक साधारण ethernet port पर ले गया। तो यहां महंगा option अपने आप safe नहीं हो जाता - इसीलिए तो मैंने recommendation नहीं, बल्कि लोगों के पास service में चल रहे modules मांगे थे।
उसी problem का एक अलग कोना, नतीजा वही। classic Omnia पर जिस एक module की मैं गारंटी ले सकता हूं वो है TP-Link TL-SM321B - 1000Base-BX bidirectional, 1310 nm, LC। kernel इसे बिना किसी मनाने-फुसलाने के उठा लेता है और मुझे इससे करीब 920 Mbit/s असली payload मिलता है। बाकी बचे 80 Mbit/s के पीछे भी किसी को भागने की ज़रूरत नहीं: line खुद 1.25 Gbit/s पर चलती है, और 8b10b encoding और Ethernet framing के बीच usable rate ठीक यहीं आकर बैठती है।
उसी router से एक counterexample: एक CTS SFP-31W2ASM10-DR Turris OS 3.x के तहत ठीक चलता था और box के 4.0 पर जाते ही मर गया - और वहां असली वजह वो नया बनाया गया VLAN और switch configuration model था, module नहीं। और यह याद रखो कि fixes कहां से आते हैं: SFP वाला काम OpenWrt master में उससे कहीं पहले चला जाता है जितनी देर में वो stable Turris branch में दिखता है, तो जो चीज़ आज link करने से मना कर रही है वो कुछ releases बाद चुपचाप जिंदा भी हो सकती है।