SONiC एक CMIS 4.0 QSFP-DD को garbled vendor fields में decode करता है जबकि SFF modules ठीक parse होते हैं
हमारी inventory tooling हर switch पर चलती है और सीधे SONiC CLI से हर pluggable के लिए vendor, part number और serial record करती है। यह हर जगह काम करती है सिवाय QSFP-DD modules के एक batch के, जहां identity fields उलझी हुई वापस आती हैं और asset database कचरे से भर जाता है।
- Switch: SONiC, QSFP-DD cages
- Module: QSFP-DD, CMIS 4.0, vendor part T-DP4CNH-NCI, label पर छपा serial L23340629 19
- उसी chassis में पुराने SFF style modules साफ-साफ decode होते हैं
$ show interface transc eeprom
Vendor Name: T-DP4CNH-NCI
Vendor PN: <unreadable>
Vendor SN: <garbled characters>
Encoding: <shifted>
Connector: <shifted>तो part number वहां आता है जहां vendor name आना चाहिए, serial अपठनीय है, और encoding व connector भी shift हो गए हैं। जो मैंने check किया:
- module reseat किया और दोबारा पढ़ा, byte for byte वही output
- label पर वाकई T-DP4CNH-NCI और L23340629 19 लिखा है, तो ये strings module के अंदर मौजूद हैं
- पड़ोसी cage में एक QSFP28 उसी command से vendor, PN और SN सही print करता है
क्या यह module अपना EEPROM गलत लिख रहा है, या CLI एक CMIS part के लिए गलत bytes पढ़ रही है? और क्या इस बीच कोई ऐसा read पाने का तरीका है जिस पर मैं असल में भरोसा कर सकूं?
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 6
आप किस branch पर हैं? 202012 में
show interfaces transceiver eepromऔर sfputil के बीच key-name की जानी-पहचानी असंगतियां थीं जो 202205 में सुलझा दी गईं, और गहरे जाने से पहले इसे rule out करना ज़रूरी है।उसी port के लिए
sudo sfputil show eeprom -dका output post करें। अगर sfputil आपको वही उलझी हुई strings देता है, तो fault shared decode path में है। अगर इसके बजाय error देता है, तो आप अलग territory में हैं - हमारे पास ऐसे platforms हैं जहां यह बसCannot get Module EEPROM data: Invalid argumentजवाब देता है और कभी कुछ decode करने तक पहुंचता ही नहीं।उसी port पर दोनों चलाए:
sudo sfputil show eeprom -dऔरshow interfaces transceiver eeprom -d। identical mangling, वही fields, जहां serial होना चाहिए वहीं वही कचरा। कहीं भी कोईInvalid argumentनहीं, read खुद बिना किसी शिकायत के गुज़र जाता है।तो दोनों commands आपस में सहमत हैं, बस गलत जवाब पर सहमत हैं। पड़ोसी QSFP28 ports दोनों में साफ रहते हैं, जिससे यह platform के बजाय इसी CMIS part की खास बात लगती है।
यह pattern एक ऐसे parser का signature है जो किसी memory map पर लगाया गया है जिसे वह समझता नहीं: vendor name field में बैठा part number, अपठनीय serial, shift हुए connector और encoding। एक टूटा हुआ module या टूटा हुआ I2C read आपको एक error या zeros का block देता है, साफ-सुथरी गलत strings नहीं।
decode path
sonic_platform_base/sonic_sfp/sfputilbase.pyमें रहता है, और वहां तीनों identity strings उन offsets से उठाई जाती हैं जो legacy SFF map के खिलाफ hardcoded हैं, चाहे plug कुछ भी हो। एक CMIS 4.0 QSFP-DD अपना identity block उन addresses पर नहीं रखता - CMIS 4.0 spec इसे section 8.3 में describe करती है - तो code सही module से genuine bytes ही पढ़ रहा है, बस वे नहीं जो उसे लगता है कि वह पढ़ रहा है, और यह उस range में जो भी है वही print कर देता है। यही वजह है कि कभी कुछ साफ-साफ fail भी नहीं होता: कोई step identifier byte को देखकर CMIS layout पर switch नहीं करता।practical निष्कर्ष यह है कि एक ऐसे parser के अलावा कुछ भी इसे सही नहीं करेगा जो CMIS map समझता हो, और जब तक वह आपके branch में नहीं आता, इस part के लिए CLI output inventory-grade नहीं है। asset database के लिए, pages को raw पढ़ें और CLI scrape करने के बजाय उन्हें खुद decode करें।
raw read के लिए, जो चाहिए वह optoe driver है: यह SFP, QSFP और CMIS EEPROMs को direct read और write के लिए expose करता है, तो आप bytes खींचकर उन्हें अपनी script में decode कर सकते हैं। फिलहाल CMIS parts के लिए asset database को यही एक चीज़ खिलाऊंगा।
अगर offsets ढूंढने जाएं तो एक चेतावनी। जो table सब quote करते हैं वह SFF वाली है - vendor name के लिए A0h bytes 20-35, PN, rev और SN के लिए 40-59। ये ठीक वही offsets हैं जो CMIS module पर आपका कचरा पैदा करते हैं, तो वहां इन्हें दोबारा इस्तेमाल न करें। bench tool की तरह किसी Linux host पर भी वही सावधानी: decoded view के लिए
ethtool -mऔर raw bytes के लिएethtool -eSFP parts के लिए ठीक हैं, पर CMIS के लिए यह print करने वाले fields पर भरोसा करने से पहले जांच लें कि आपका build असल में क्या समझता है।CMIS handling EEPROM decoder से भी ज़्यादा जगहों पर पतली है। हमने InnoLight 800G QSFP-DD optics की एक tray service में डाली, T-DP8CNH-NNO और T-DP8CNT-NNO, और लगभग हर दूसरी insertion हमें एक मरा हुआ port दे गई: datapaths ने DataPathDeactivated report किया, log में 'ConfigSuccess' के लिए एक timeout था, और वहां से port हमेशा के लिए down रहता - न कोई retry, न कुछ जो अपने आप वापस लाए।
culprit निकला
decommission_all_datapaths()cmis.py में। यह पूरी sequence एक के बाद एक चलाता है - DEINIT, application ID को 0 पर clear करना, फिर INIT - और अगला step शुरू करने से पहले कभी check नहीं करता कि पिछला step असल में लागू हुआ या नहीं। हमारे parts को ठीक वही confirmation चाहिए, तो datapath आधा-configured रह जाता है और state machine बस अपना timer बैठे-बैठे बिता देती है। असली fix को asynchronously wait करना होगा, क्योंकि xcvrd की inline CMIS state machine के अंदर block नहीं किया जा सकता, और आखिरी बार जो मैंने देखा किसी ने एक बनाकर land नहीं किया था। अलग bug, वही theme: SFF parts के लिए लिखे code पर टांका हुआ एक CMIS path।इस जो दिशा बन रही है उसमें एक correction, क्योंकि दो failure modes लगातार मिल जाते हैं।
Cannot get Module EEPROM data: Invalid argument, या driver ठीक होने तक power cycle के बाद sfputil से गायब हो जाने वाला एक QSFP, या ऐसा platform जो get_transceiver_info implement ही नहीं करता - ये platform और driver के gaps हैं, और ये किसी भी decoding होने से पहले ही आपको रोक देते हैं।यहां जो बताया गया है वह इसका उल्टा है: एक पूरा, successful read जिसे फिर गलत field layout से interpret किया जाता है। इस पर modules न बदलें या driver versions के पीछे न भागें। उस module के अंदर bytes ठीक हैं, और कोई भी tool जो उन्हें CMIS की तरह decode करे, आपको label वाला serial दिखा देगा।