SONiC के QSFP28 cage में QSA adapter: 10G optic का link आ जाता है पर DDM नहीं मिलता
हम एक whitebox switch पर, जो SONiC चला रहा है, ढेरों 10G optics फिर से इस्तेमाल कर रहे हैं, तो कुछ QSFP28 cages में QSA-style adapters (10GTek QSA-100A) लगे हैं जिनमें plain 10G SFP+ modules जाते हैं। Mechanically और electrically सब ठीक है। गड़बड़ management side पर होती है।
- switch: 1U whitebox, उसी platform के लिए बना SONiC
- adapters: 10GTek QSA-100A, QSFP28 cage से SFP+
- optics: एक decommission किए गए access switch से निकले 10G SFP+ modules
- वही optics दूसरे box में native SFP+ cage में normally पढ़ते हैं
adapted ports पर मुझे यह दिखता है:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the port
अब तक यह try किया:
- दूसरा adapter और दूसरा optic लगाकर देखा, behaviour वही रहा;
- pair को अलग QSFP28 cage में shift किया, result वही;
- confirm किया कि वही optics कहीं और native SFP+ port में पूरा diagnostics देते हैं।
क्या यह diagnostics data की कमी वो चीज़ है जो एक passive adapter carry ही नहीं कर सकता, या मामला switch की software side का है? और अगर software है, तो fix कहां होना चाहिए: platform layer में या generic transceiver code में?
Comments 7
Platform code में घुसने से पहले, एक सवाल जो मामले को आधा-आधा बांट देता है। उसी cage में एक native QSFP28 module लगाओ: क्या उससे diagnostics मिलता है, या उस port पर DDM हमेशा मरा रहता है चाहे कुछ भी लगाओ?
अगर native part ठीक पढ़ता है, तो cage और I2C path सही हैं और पूरा मामला इस पर आ जाता है कि port driver adapter से आने वाली चीज़ को कैसे interpret करता है। अगर native part भी blank आता है, तो thread आगे पढ़ना बंद कर दो, यह अलग fault है और adapters से इसका कोई लेना-देना नहीं।
management interface में यह well known और काफी boring सा फर्क है, और यहां adapter का कोई दोष नहीं।
SFP side पर दो I2C addresses काम में आते हैं: identification data 0x50 पर रहता है, diagnostics map 0x51 पर। एक QSFP part यह सब 0x50 के नीचे ही रखता है और pages switch करके बाकी तक पहुंचता है। तो जिस driver को बताया गया है कि cage QSFP है, वह pages सिर्फ एक ही address पर ढूंढता है और 0x51 से कभी कुछ नहीं पूछता। identification इतना plausible आ जाता है कि port up हो जाए, diagnostics बस कभी resolve ही नहीं होता, जो ठीक वही shape है जो आपने post की।
fix platform layer में है, न कि optic में और न adapter में। हर platform अपना खुद का SfpUtil implementation भेजता है; आपके यहां उस port को QSFP की जगह SFP cage declare करना होगा। जब तक कोई यह नहीं करता, adapted ports पर DDM/DOM खाली रहेगा। उसके बाद module वैसे ही पढ़ा जाएगा जैसे native SFP+ cage में पढ़ा जाता।
एक live link जिसके पीछे diagnostics में कुछ भी नहीं, इन ports पर गलत software का यही रूप होता है। यह किसी marginal optic का रूप नहीं है।
standards का नाम लेना ठीक रहेगा, क्योंकि फिर फर्क साफ दिखता है। SFP side SFF-8472 है, जहां diagnostics अपने अलग memory map में रहता है और दूसरे address पर मिलता है। QSFP और QSFP28, SFF-8636 follow करते हैं, और नए parts CMIS, जहां सब कुछ एक ही address पर page select के पीछे टिका होता है।
adapter यह पुल नहीं बना सकता। यह एक passive mechanical और electrical part है, management wires इसके अंदर से सीधे निकल जाते हैं और रास्ते में कुछ भी translate नहीं होता। तो host को यह बताना ज़रूरी है कि एक byte पढ़ने से पहले दोनों memory models में से कौन सा लागू है, और adapter के पास यह बताने का कोई तरीका नहीं।
तुलना के लिए, Dell ONIE hardware पर यही class की problem ज़्यादा ज़ोर से काटती है। एक 407-BBRO QSA जिसके अंदर 407-BBOU 10GBASE-SR SFP+ (SFP-10GSR-85) लगा है, S4048-ON के 40G ports में और S6010-ON के किसी भी port में, दोनों OpenSwitch OPX 3.1 dev2 चला रहे हैं:
opx-ethtool media को सही पहचानता है, transceiver को enabled और qualified मार्क करता है, admin state up, supported speeds 1000, 10000 और 40000 Mbps, और port फिर भी कभी up नहीं होता, चाहे speed, duplex या autoneg कुछ भी set करो, defaults भी शामिल। किसी ने OPX platform-config repository पर इसे enhancement request के तौर पर खोला था, यह कहते हुए कि यहां QSA को काम करने दिया जाए, और कभी किसी ने जवाब नहीं दिया। वह अब भी open पड़ा है।
यह न vendor lock है, न कोई खराब optic। बस उस cage को network OS कभी adapter mode में डालता ही नहीं, और interface settings का कोई भी combination आपके लिए यह नहीं करेगा।
जुड़ा हुआ ज़रूर है, पर दोनों cases को एक साथ मत मिलाओ। original post में एक working link है जिसमें सिर्फ diagnostics missing है: data path ठीक है, सिर्फ management read गलत है, और platform SfpUtil को patch करने से यह ठीक हो जाता है। Dell वाला case ऐसा port है जो कभी up ही नहीं होता, क्योंकि उस cage के लिए port profile शुरू से apply ही नहीं होता। यह एक layer नीचे बैठा मामला है और इसे अपना अलग fix चाहिए।
जल्दबाज़ी में symptoms मिलाने वाला कोई एक पूरा दिन transceiver code दोबारा लिखने में जला सकता है जबकि उसका port किसी बिल्कुल अलग वजह से down है।
"adapter एक software feature है" वाली बात का एक और रूप, mechanical नहीं। Z9264F-ON पर OS10 10.5.2.7 के तहत, 10G SFP+ media के लिए QSA28 adapters इस्तेमाल करने का मतलब है port को उसी port-group profile में डालना जो 4x10G breakout cable इस्तेमाल करता है:
उस platform पर port-group profiles QSFP28 ports की जोड़ियों पर काम करते हैं, तो इसे apply करने से हर जोड़ी का partner port disable हो जाता है। QSA28 एक single interface है और फिर भी आपको breakout जैसी कीमत चुकानी पड़ती है: 64 usable ports घटकर 32 रह जाते हैं। न OS10 user guides और न ही Dell optics spec sheet single-port QSA mode document करते हैं।
अगर उस box पर आपको बहुत सारा native 10G चाहिए, तो 2:1 loss के लिए पहले से plan करो या rack में अलग 10G switch लगाओ।
इनकी एक tray order करने से पहले, मैं list में दो checks रखूंगा। क्या network OS ठीक उसी platform के लिए QSA support declare करता भी है, और अगर करता है, तो उसे on करने की कीमत क्या है: ports, diagnostics, या एक profile जो पड़ोसी cage को भी साथ खींच ले जाए। fit कभी issue नहीं होता, इनमें से हर adapter बिना किसी शिकायत के cage में चला जाता है।
इस thread के cases सिर्फ इसमें अलग हैं कि software कितनी दूर तक जाता है। SONiC पर आपको ऐसा कुछ मिलता है जो आप खुद fix कर सकते हैं, port को SFP declare करो और diagnostics वापस आ जाता है। ऊपर वाले Dell platforms पर आप किसी और के platform code का इंतज़ार कर रहे हो, और adapters या optics बदलने से वह बिल्कुल नहीं हिलेगा।