Edgecore AS9716-32D: PDDF के तहत sfputil एक 400G QSFP-DD module को QSFP28 के रूप में decode करता है
हम lab में PDDF platform layer वाली एक community SONiC image पर एक जोड़ी AS9716-32D को 400G spine के तौर पर bring up कर रहे हैं। optics कोई समस्या नहीं हैं, peer ठीक से link करता है, लेकिन switch उनके बारे में जो भी कहता है वह गलत है।
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- इस platform के लिए PDDF वाला community SONiC build
- पहले cage में 400G QSFP-DD module (NeoPhotonics part)
read खुद सफल होता है, module सूचीबद्ध है, और cage को QSFP28 बताया जाता है:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsगड़बड़ यहीं Identifier वाली लाइन में है। यह एक QSFP-DD part है, तो नीचे की bytes को CMIS के बजाय SFF-8636 field set के हिसाब से decode किया जा रहा है, और उसके बाद के fields noise जैसे दिखते हैं।
अब तक जांचा:
- module खुद ठीक है, वही part दूसरे platform पर सही पढ़ता है और दूसरे छोर पर light दिखती है;
- reseat करने और दूसरे cage में ले जाने से कुछ नहीं बदलता, सभी 400G ports एक जैसा व्यवहार करते हैं;
- PDDF device description में ये cages QSFP28 declared हैं और optoe1 से bound हैं।
क्या यह आखिरी बात ही पूरा जवाब है, क्या QSFP-DD cages को बस एक अलग optoe device चाहिए, और क्या platform description edit करना इसे ठीक करने का माना हुआ तरीका है, या इसके ऊपर भी कुछ चीज़ को cage type सीखने की ज़रूरत है?
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
आपका लक्षण बिल्कुल binding से मेल खाता है, तो optics में आगे देखने की ज़रूरत नहीं।
AS9716-32D के लिए PDDF device description 400G cages को QSFP28 declare करता है और उन्हें optoe1 से bind करता है। optoe1 वही SFF-8636 EEPROM layout देता है जो QSFP+ और QSFP28 इस्तेमाल करते हैं, तो एक CMIS module गलत map से पढ़ा जाता है और identifier के बाद सब कुछ noise जैसा दिखता है। जो port type आप देख रहे हैं वह detect ही नहीं हुआ, वह बस वही है जो description कहता है।
QSFP-DD, CMIS को follow करता है, और CMIS को optoe3 serve करता है। fix यह है कि उन cages के लिए PDDF device description में दोनों fields पलट दें: type को QSFP28 से QSFP-DD, और driver को optoe1 से optoe3। मैंने यह उसी box पर एक 400G NeoPhotonics part के साथ verify किया, और बदलाव के बाद
sfputil show eeprommodule को ठीक से decode करके लौटाता है।दो caveats। यह platform data है, तो जब तक बदलाव उस image में नहीं है जो आप build करते हैं, एक image upgrade खुशी-खुशी पुरानी description वापस रख देगा। और upstream में ठीक यही बदलाव approve हुआ था लेकिन pull request बिना merge हुए बंद कर दिया गया, यह काम एक बाद वाले change में समा गया, तो यह मान कर मत चलें कि आपकी image में यह पहले से है। पहले अपने platform की device description पढ़ लें, एक मिनट में पता चल जाएगा कि आप कुछ पीछे भाग भी रहे हैं या नहीं।
किसी भी platform file को छूने से पहले, उस port पर raw dump post करें:
sudo sfputil show eeprom -d। अगर सभी bytes मौजूद हैं और सिर्फ interpretation गलत है, तो यह binding की समस्या है, module की नहीं, और कोई RMA की बात शुरू करने से पहले यह फर्क समझना दस मिनट के लायक है।बाकी आधा हिस्सा आपने खुद ही जवाब दे दिया है। optoe1 वह SFF-8636 flavour है जो QSFP+ और QSFP28 इस्तेमाल करते हैं, तो इससे पढ़ा गया एक CMIS module identifier से आगे बिगड़ा हुआ निकलता है, जो ठीक वही output है जो आपने paste किया। एक बार जब description किसी QSFP-DD cage के लिए optoe1 नाम लेती है, तो module की तरफ शक करने को कुछ नहीं बचता।
तो उन cages में से किसी एक के लिए PDDF device description की संबंधित लाइनें भी paste कर दें। इससे पता चलेगा कि सिर्फ driver field गलत है या declared cage type भी।
यही थी बात। Cage type QSFP-DD पर, driver optoe3 पर, reload, और अब module ठीक से decode होता है,
sfputil show eepromअब cage को QSFP28 नहीं कहता। मैंने यह बदलाव running switch को patch करने के बजाय हमारी build वाली image में डाला, ठीक ऊपर वाले upgrade वाले कारण से।बाद में यह पढ़ने वाले किसी के लिए एक ईमानदार बात: यह सिर्फ EEPROM पढ़ने का तरीका ठीक करता है, इससे ज़्यादा कुछ नहीं। इस platform पर बाकी transceiver plumbing की अपनी अलग दिक्कतें अभी भी हैं और मैं box को पूरी तरह सुलझा हुआ नहीं कहूंगा।
चूंकि आपने बाकी दिक्कतों का ज़िक्र किया, यह रही वह जो उसी platform पर आपका इंतज़ार कर रही है। SONiC master build चला रहे हमारे AS9716-32D (x86_64-accton_as9716_32d-r0) पर,
sudo sfputil show presenceभरे हुए ports को Present बताता है और उनका EEPROM ठीक से पढ़ लेता है, जबकिshow interfaces transceiver presenceहर port को Not present बताता है। Syslog में यह बार-बार आता है:और CLI से EEPROM पढ़ने पर RuntimeError('PddfEeprom is not Programmed') मिलती है। यह reboot के बाद कभी भी randomly आ जाता है और इसका कोई root cause कभी post नहीं हुआ, तो वहां sfputil ही एकमात्र presence check है जिस पर मुझे भरोसा है।
बेजोड़ लेकिन उसी area की बात: ये दोनों commands 202012 branch में key names पर भी असहमत होने के लिए जाने जाते हैं, जिसे 202205 में साफ किया गया। अगर आपके outputs content में नहीं बस शब्दों में अलग हैं, तो शायद बस इतनी ही बात है।