LibreNMS में ZXA10 OLTs: port pages पर कोई transceiver dBm नहीं, और fan व PSU sensors गायब हो गए
हम LibreNMS से ZTE ZXA10 OLTs के एक mixed fleet को poll करते हैं और दो चीज़ें गलत हैं। मुझे शक है कि वो आपस में जुड़ी नहीं हैं, पर पक्का नहीं।
- V2.1.0 पर ZTE ZXA10 C300, अब भी एक पुराने POP में service में
- V2.0.30 पर ZTE ZXA10 C620, साथ में एक C650 और C650E
- एक ZTE ZXA10 C320 जो पहले ठीक चलता था
- SFP और SFP+ uplinks, उनके नीचे GPON cards
पहली समस्या: port pages पर कोई transceiver sensors हैं ही नहीं। dBm में कोई receive या transmit power नहीं, कोई module temperature नहीं, कोई supply voltage नहीं, कोई laser bias current नहीं। यही वो नंबर हैं जो मुझे subscribers की कॉल आने से पहले किसी गंदे connector को पकड़ने के लिए चाहिए।
दूसरी समस्या: वो state sensors जो C320 पर काम करते थे, fans, power supplies और card state, एक rediscovery के बाद चुपचाप गायब हो गए। log में कोई error नहीं, कुछ भी fail नहीं हुआ, वो बस अब device पर हैं ही नहीं।
boxes को हाथ से walk करने पर, optical data साफ तौर पर MIB में कहीं है, पर जो OID एक platform पर जवाब देता है वो दूसरे पर कुछ नहीं लौटाता:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1अब तक जो आज़माया:
- हर device पर rediscovery और एक full poll
- एक ही OID पर C650 और C300 के जवाबों की तुलना
- यह चेक करना कि कहीं खाली cages ही discovery के हार मानने की वजह तो नहीं
ZXA10 family पर optical readings असल में रहती कहां हैं, और किस वजह से कोई state sensor बिना कुछ भी log किए discovery पर गायब हो जाता है?
Comments 5
दोनों जानी-पहचानी हैं, और जैसा तुमने अंदाज़ा लगाया वो आपस में जुड़ी नहीं हैं।
तुम्हें कौन सी optical table मिलती है यह platform पर depend करता है, और दोनों कभी एक box पर साथ नहीं रहतीं। पुराना C300, यहां V2.1.0 के खिलाफ test किया गया, zxAnOpticalModuleMonTable expose करता है:
V2.0.30 पर C620, C650 और C650E इसकी बजाय zxAnOpticalModuleInfoTable expose करते हैं:
कोई भी table तुम्हें वही चार readings देती है: dBm में rx और tx power, module का temperature, supply voltage, laser bias current। raw values को 0.001 scaling चाहिए। दो sentinels को भी filter करना ज़रूरी है, वरना chassis का हर खाली cage तुम्हें alarm देगा: एक unsupported port या unpopulated cage 2147483647 जवाब देता है, और एक dark port -80000 जवाब देता है। Card presence optical polling में आती ही नहीं, वो एक अलग operational-status state sensor है जो unpopulated slots को skip करता है।
तुम्हारे गायब fans, PSUs और card state एक अलग bug हैं। platform YAML में state entries से value: key गायब थी, और उसके बिना discovery table name को ही एक column की तरह पढ़ने लगता है, कुछ काम का नहीं पाता और चुपचाप sensor drop कर देता है, कहीं कोई error नहीं, इसीलिए तुम्हें यह सिर्फ एक कमी के तौर पर दिखा। key वापस डालने से यहां C320 fixture पर छह sensors लौट आए।
इसके इर्द-गिर्द plan बनाने से पहले एक सही चेतावनी: यह अभी भी merged नहीं बल्कि open एक change में सवार है, और review पहले ही उसमें से ethernet error monitoring को out of scope कहकर काट चुका है। इसे एक ऐसे patch की तरह लो जो तुम खुद साथ रखते हो, किसी इंतज़ार करने लायक fix की तरह नहीं।
उन में से हर box जो sysDescr रिपोर्ट करता है वो हमें दिखाओ। optical MIB के लिहाज़ से C300, C320, C620, C650 और C650E एक family नहीं हैं, तो जो OID उनमें से कुछ पर जवाब देता है और बाकियों पर चुप रहता है वो fault नहीं, expected है।
जो दो सबसे ज्यादा अलग हैं, C300 और C650s में से एक, उन पर उस OID की walk की पूंछ पोस्ट करो जो तुम पहले ही आज़मा चुके हो। अगर एक जवाब देता है और दूसरा खाली है, तो यही पूरी कहानी है और fix per-platform है।
अपनी दोनों समस्याओं को अलग भी रखो। गायब fan और PSU sensors एक discovery definition वाला मुद्दा है, और उसका इससे कोई लेना-देना नहीं कि OLT कौन सी optical table implement करता है।
दूसरी तरफ से इस कमी की पुष्टि कर रहा हूं। मैंने 25.8.0-dev पर इसी family के बारे में पूछा था: एक C320 GPON OLT, और मुझे चाहिए था दोनों सिरों पर, OLT और ONUs दोनों पर, GPON ports की graphing - rx और tx power levels, हर link कितनी दूरी नापता है, per-port utilisation - साथ ही यह भी कि क्या family के लिए कहीं पहले से कोई template मौजूद है।
वो बिना किसी के OIDs, कोई walk या कोई method पोस्ट किए बंद हो गया, तो यह बस इतना ही documents करता है कि C320 family के लिए out-of-the-box coverage आधा-अधूरा है। पीछे मुड़कर देखूं तो मुझे request के साथ एक walk attach कर देनी चाहिए थी। अगर तुम वैसे भी यह बना रहे हो, तो ONU optical levels वो हिस्सा है जो किसी ने नहीं किया, और हममें से काफी लोग इसे इस्तेमाल करेंगे।
यह fleet जो करता है उससे मेल खाता है। C300, .1.3.6.1.4.1.3902.1015.3.1.13.1 पर जवाब देता है और दूसरे OID पर कुछ नहीं लौटाता, C620 और C650 इससे उल्टा हैं, और C650E, C650 जैसा व्यवहार करता है।
Values integers की तरह वापस आते हैं जिन्हें 0.001 scaling चाहिए, बिल्कुल जैसा बताया गया। जो शुरू में कचरा जैसा लग रहा था वो अब समझ आता है: 2147483647 उन cages पर जिन्हें हमने कभी populate नहीं किया, और -80000 दो ports पर जहां दूर वाला सिरा power off है। दोनों sentinels यहां असली हैं, तो जो कोई भी raw numbers के खिलाफ thresholds लिखेगा उसे एक बहुत शोर-शराबे वाली alert list मिलेगी।
platform YAML भी चेक की और हमारी तरफ भी value: key गायब है। change अभी भी open है तो इसे locally carry करूंगा। दोनों समस्याओं को अलग करना ही वो हिस्सा था जो मैंने शुरू से गलत समझा था।
इसे बनाते वक्त एक बात ध्यान में रखने लायक है: DOM data हर जगह एक subset है, सिर्फ ZTE पर नहीं।
SONiC में एक CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 का EEPROM बिना किसी परेशानी के पढ़ लिया जाता है, और TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR के साथ TRANSCEIVER_STATUS सब identity के साथ-साथ temperature, voltage, per-lane bias और power से भर जाते हैं, पर control और status group बस मौजूद ही नहीं होता: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode और get_power_override database view में कुछ नहीं लौटाते, तो अगर तुम्हें वो bits चाहिए तो खुद जाकर platform API से मांगने पड़ते हैं।
firewall side से भी वही सीख। PAN-OS पर, show transceiver-detail all diagnostic block print करता है, और पढ़ने वाली पहली field diagnostic-monitor है। अगर वो No कहती है, तो module digital optical monitoring implement नहीं करता और हर value N/A वापस आती है। वहां कुछ भी टूटा नहीं है, बस पढ़ने को कुछ है ही नहीं। अपने alerting में यह फर्क encode करना ठीक रहेगा ताकि बिना DOM वाला module किसी dead port जैसा न दिखे।