Edgecore AS5114-48X, dentOS पर: port 18 में SFP+ ठीक से enumerate होता है पर onlpdump RX_LOS पर ही रहता है
lab rack में हम test के लिए कुछ ONIE boxes रखते हैं, और उनमें से एक Edgecore AS5114-48X-O-AC-F-EC है जो dentOS पर चलता है। Port 18 को एक पड़ोसी switch तक 10G link ले जाना चाहिए और यह up होने से साफ इनकार करता है, भले ही platform को module साफ दिखता है।
- Switch: Edgecore AS5114-48X-O-AC-F-EC, dentOS (ARM64)
- Module: port 18 में Intel FTLX8571D3BCV-IT SFP+
- दूर वाले सिरे तक Duplex LC patch cord, working ports वाले cords जैसा ही batch
kernel module से पूरी तरह खुश है और platform layer इसे enumerate कर लेता है, पर status bit कुछ और ही कहानी बताता है:
kernel: ... port 18: switched to inband/10gbase-r link mode
$ onlpdump
...
sfp @ 18 = Present
Status: 0x00000004 [ RX_LOS ]अब तक जो किया:
- module reseat किया और दोनों connectors साफ किए
- दूर वाले सिरे पर TX और RX बदले, फिर पूरा patch cord एक known good वाले से बदला
- वही module दूसरे free port में लगाया, वहां भी वही picture
तो EEPROM ठीक पढ़ता है और MAC side 10gbase-r में switch हो जाता है, पर receiver को कभी light दिखता ही नहीं। इसे module, fibre plant और platform के बीच साफ-साफ कैसे बांटूं, जब onlpdump मुझे बस एक presence flag और status bitmask देता है और कुछ नहीं?
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 5
RX_LOS अपने आप में सिर्फ यह कहता है कि receiver को पर्याप्त light नहीं दिख रही, तो box को दोष देने से पहले: दूर वाला सिरा क्या report करता है? अगर peer port DDM दिखाता है, तो उसका Tx power पढ़ें और confirm करें कि laser वाकई on है और port shut नहीं है। यह जानना भी ज़रूरी है कि दोनों सिरे एक ही optic type और fibre mode के हैं या नहीं - एक short reach module का long reach वाले के सामने होना, या गलत fibre, बिल्कुल ऐसा ही दिखता है।
और क्या आपने port 18 में किसी अलग part number का दूसरा module try किया, या सिर्फ यही एक module ports के बीच घुमाया?
दूर वाला सिरा दूसरे switch पर एक 10G port है, दोनों तरफ वही short reach optics। वह port उसी patch cord पर एक अलग module के साथ खुशी-खुशी link करता है, तो peer वाला laser ज़िंदा है और fibre path end to end ठीक है। Port 18 admin up है, और cord उलटने पर भी वही नतीजा मिलता है।
परेशान करने वाला हिस्सा यह है कि locally मैं क्या देख पाता हूं: onlpdump मुझे presence और status bitmask देता है, बस इतना ही। dentOS वाली तरफ मेरे पास दूर वाले सिरे से compare करने के लिए कोई Rx figure नहीं है, तो मैं "कुछ receive नहीं हो रहा" पर अटका हूं, यह जाने बिना कि कौन सा सिरा।
Symptom से cause तक, जिस क्रम में मैं इस पर काम करूंगा। Detection सिर्फ I2C/EEPROM path और MAC plumbing साबित करता है, और कुछ नहीं। inband/10gbase-r वाली kernel line host side का खुद को configure करना है - इसका मतलब यह नहीं कि एक भी photon पहुंचा। RX_LOS asserted होने पर तीन suspects बचते हैं: एक dark या crossed fibre, एक दूर वाला सिरा जो transmit नहीं कर रहा, और एक receiver जो इस platform में काम नहीं करता।
पहले दो पर आप पहले ही ज़ोर लगा चुके हैं, तो bits जमा करना बंद करें और एक number लें। कोई भी switch जो digital diagnostics print करता हो, चलेगा। EXOS पर यह
show ports <port> transceiver informationहै, जो temperature, supply voltage, laser bias, Tx और Rx power देता है और module thresholds से बाहर हर value को flag करता है, औरdebug hal show optic port <port>EEPROM से vendor, part number, serial, connector और wavelength जोड़ता है। मैंने एक X460-G2-24x-10G4 पर मरे हुए 10G port को इसी तरह पकड़ा था और receiver पर लगभग -26.78 dBm मिला, जिस पर कोई भी 10G short या long reach receiver lock नहीं करेगा।अगर दूर वाला सिरा आपके module के transmit करते समय एक Rx reading दे सके, तो कम से कम यह पता चलेगा कि उसका laser काम करता है या नहीं। उसके बाद जो बचता है वह यह कि platform इस particular part को drive नहीं कर रहा।
यहां भी वही box है, और इस platform पर module support standard के हिसाब से नहीं, part के हिसाब से है। हमारे AS5114-48X पर Avago AFBR-703SDZ-IN2 rev G2.3 बिना किसी tuning के आ जाता है - platform इसे Intel Corp बताता है, serial AA1329A5UTA के साथ, जो पहली नज़र में लोगों को उलझा देता है।
दो parts हमारे लिए उसी switch पर उसी fibre पर कभी काम नहीं आए: जो आपके पास है वह Intel FTLX8571D3BCV-IT rev A, और एक OPNEXT TRS5020EN-S301। दोनों detect हुए, दोनों बिल्कुल आपके port 18 जैसे बैठे रहे। fibre plant पर एक और शाम बिताने से पहले कोई known good part उधार लें।
उस bit के बारे में सटीक रहना ज़रूरी है: RX_LOS module का अपना loss-of-signal output है, जैसा SFF-8472 में defined है, और platform layer इसे बस status 0x00000004 की तरह दिखाता है। यह receiver की LOS threshold से नीचे assert होता है, तो यह आपको "पर्याप्त light नहीं" बताता है, कभी क्यों नहीं। यही वजह है कि एक बिल्कुल साफ EEPROM read और एक मरा हुआ optical path बिना किसी विरोधाभास के साथ रह सकते हैं।
एक असली Rx number पर ज़ोर देने की दूसरी वजह: CLI से attenuation बिल्कुल incompatibility जैसा दिखता है। एक colleague के पास एक Zyxel port करीब -25.69 dBm पर बैठा था, और fix patch cord और एक ऐसा patch panel था जिसे किसी ने फिर से काम किया था, module नहीं। अगर dentOS वाली तरफ DDM नहीं पढ़ सकते, तो इसे दूर वाले सिरे से या किसी host से पढ़ें - सिर्फ एक bitmask इसे तय नहीं करेगा।