nxos_ssh पर NAPALM का get_optics, QSFP-100G-CWDM4 modules के लिए सिर्फ lane 1 का DOM लौटाता है
मैं कुछ Nexus 9000 fabrics के लिए monitoring में per-port optical telemetry जोड़ रहा हूं। Collection NAPALM से होता है, और जिस getter पर मैं भरोसा करता हूं वो get_optics() है।
- Nexus 9000 leaf और spine pairs
- fabric links पर QSFP-100G-CWDM4 modules
- nxos_ssh driver वाला NAPALM, SSH transport, अभी तक NX-API enabled नहीं
एक four-lane 100G module पर getter ठीक एक ही channel वापस देता है:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}switch के पास खुद यह data साफ मौजूद है - show interface transceiver details सभी चार lanes के लिए Rx power, Tx power और bias current print करता है - तो यह platform से ज़्यादा parser का मामला लगता है।
मैंने जो check किया:
- जो भी QSFP-100G-CWDM4 port मैं poll करता हूं उस पर वही result, तो यह कोई एक अजीब module नहीं है
- SFP+ ports सही वापस आते हैं, जो समझ आता है जब report करने को सिर्फ एक ही lane हो
- driver की optics parsing पढ़ी और ऐसा लगता है कि सिर्फ पहला DOM block ही कभी उठाया जाता है
क्या कोई असल में NX-OS पर NAPALM से per-lane DOM collect कर रहा है, या सब आखिर में switch का output खुद scrape करते हैं?
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
बिल्कुल कौन सा NAPALM version, और वो leaves किस NX-OS train पर हैं? nxos_ssh में optics code एक से ज़्यादा बार reworked हुआ है, और switch पर transceiver output भी हर train में एक जैसा format नहीं होता, तो कोई इसे bug कहे उससे पहले दोनों हिस्से मायने रखते हैं।
अपना parser लिखने जाने से पहले एक चीज़ करने लायक है: किसी एक SFP+ port पर get_optics() call करो और उस structure को CWDM4 वाले के बगल में रखो। अगर दोनों एक जैसे skeleton के साथ वापस आएं और सिर्फ values अलग हों, तो driver text को ठीक से walk कर रहा है और बस पहले matching block के बाद छोड़ देता है। अगर उनकी shape अलग है, तो वो QSFP ports पर per-lane section तक पहुंचता ही नहीं। ये दो अलग fixes हैं, और SFP+ output इन्हें अलग बताने का सबसे सस्ता तरीका है।
दोनों collectors पर PyPI से current release, और leaves व spines एक ही NX-OS train पर हैं, तो जहां भी point करूं वही चीज़ वापस मिलती है - कोई एक अजीब box नहीं।
आपने जो SFP+ comparison मांगी वो कर ली। दोनों cases में skeleton एक जैसा: physical_channels.channel जिसमें index 0 पर एक ही element है, तीनों values भरी हुई। एक-lane module के लिए सही जवाब, CWDM4 के लिए गलत। तो parser output के per-lane हिस्से को ढूंढने में नाकाम नहीं हो रहा, वो एक block match करता है, उसे भरता है और वहीं रुक जाता है। जब मैंने code पढ़ा था तब भी यही लग रहा था, मैं बस किसी से confirm करवाना चाहता था कि मैं गलत नहीं पढ़ रहा।
यह आपकी तरफ की किसी चीज़ की बजाय driver का एक gap है। nxos_ssh के खिलाफ एक open pull request है जो optics parsing दोबारा लिखता है: हर lane physical_channels.channel के नीचे अपना खुद का element बनकर वापस आती है, index 0 पर walk रुकने की बजाय, और हर element अपना Rx level, Tx level और laser bias current लाता है। इसके साथ आने वाली fixtures एक four-lane QSFP-100G-CWDM4 पर बनी हैं, तो यह ठीक आपके module के खिलाफ लिखा गया था। मैंने इसे सिर्फ एक lab box पर चलाया है, तो इसे production collector के लिए recommendation की बजाय try करने लायक चीज़ मानो।
जब तक यह किसी installable release में नहीं आता, practical रास्ता यह है कि 100G ports के लिए getter छोड़ दो और
show interface transceiver detailsखुद parse करो, फिर हर lane को monitoring में अपनी series के तौर पर push करो। थोड़ा ज़्यादा code खुद संभालना पड़ेगा, पर फिर तीन-चौथाई signal फेंकना बंद हो जाता है।जो भी रास्ता चुनो, per lane alert रखो। CWDM4 पर एक degraded lane पूरे link को नीचे खींच लेगी बिना कभी दिखे अगर आप सिर्फ lane 1 देख रहे हो।
Nexus पर per-lane visibility लोगों की उम्मीद से ज़्यादा मायने रखती है।
हम एक Nexus 9000 पर एक Cloud Scale defect में फंस गए थे, जहां QSFP-100G-SR4-S 4x25G में split था। चार 25G ports में से सिर्फ एक चाहिए था, बाकी तीन बंद रहे, और जिसकी परवाह थी वो कभी link ही नहीं हुआ। जिस चीज़ ने हमें निकाला वो था पूरे group को पहले up लाना - चारों sub-interfaces पर
no shutdown- lane 1 को settle होने देना, फिर बाकी तीन spares को दोबारा shut करना। वहां रहते हुए group भर में FEC भी एक जैसा रखो; किसी एक lane पर अजीब setting शराफत से उसी lane पर नहीं रुकती।बात यह है कि dashboards में सिर्फ lane 1 के साथ आप उस ज़्यादातर चीज़ से अंधे हो जो एक 100G port कर रहा होता है। extra parsing अपनाने लायक है।