Nokia 7705 पर LibreNMS discovery Column 'channels' cannot be null के साथ मर जाती है और कोई DOM collect नहीं करती
हम LibreNMS में मुट्ठी भर Nokia 7705 aggregation routers poll करते हैं, और मुझे उनसे optical DOM चाहिए था, हमेशा वाली वजह से, ग्राहक के notice करने से पहले किसी span का soft होना पकड़ना। इन devices पर discovery कभी पूरी नहीं होती।
- Nokia 7705, TiMOS चला रहा है
- LibreNMS 26.3.1
- ports में सामान्य single-lane 1G SFPs, अलग-अलग vendors, कुछ पुराने
- SNMP बाकी सब जगह healthy है: interfaces, CPU, memory और traffic सब ठीक poll होते हैं
Discovery हर बार यहीं रुक जाती है:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be null
और नतीजा यह होता है कि पूरे router के लिए न कोई transceiver entries, न कोई optical sensors, एक खराब port के साथ बाकी काम करते हों ऐसा नहीं, पूरा device खाली वापस आता है।
मैंने क्या किया:
- अकेले उसी device के लिए discovery फिर से चलाई, वही error वहीं point पर
- device delete करके फिर से add किया: वह create होता है, फिर discovery उसी जगह मर जाती है
- उसी installation में बाकी vendors transceivers और DOM सामान्य तरीके से discover करते हैं, तो यह मेरी तरफ की टूटी database जैसा नहीं लगता
क्या यह TiMOS discovery की जानी-पहचानी problem है, और इन routers के लिए transceiver discovery बंद करने के अलावा इसके बारे में कुछ किया जा सकता है?
Comments 3
जानी-पहचानी है, और यह तुम्हारी database नहीं है।
TiMOS discovery code TIMETRA-PORT-MIB::tmnxPortSFPNumLanes से lane count निकालता है और जो भी मिले उसे सीधे
channelscolumn में डाल देता है, जो NULL स्वीकार नहीं करता। पुराने single-lane optics आमतौर पर गुनहगार होते हैं: agent उनके लिए वह object कभी populate ही नहीं करता, तो port insert को एक null थमा देता है, insert फट जाता है, और यह failure पूरे device की transceiver discovery को अपने साथ नीचे ले जाती है। इसीलिए तुम odd module वाले एक port की बजाय हर port खो देते हो।निकलने के दो रास्ते। सबसे साफ है LibreNMS को आगे बढ़ाना, upstream में accepted change LibreNMS/OS/Timos.php में value को guard करता है, ताकि गायब या खाली lane count को एक single channel माना जाए और बाकी कुछ भी integer में force हो जाए। अगर अपने current release पर अटके हो, तो वही guard उस file में हाथ से डाल दो; यह बस कुछ lines हैं, हालांकि अगली update में अगर भूल गए कि यह वहां है, तो गायब हो जाएगा।
कुछ भी patch करने से पहले, router पर TIMETRA-PORT-MIB::tmnxPortSFPNumLanes को walk करो। जो भी ports खाली जवाब देते हैं वही insert को मार रहे हैं, और यह जानना worth है कि उनमें कौन से optics बैठे हैं।
दोनों बातों की पुष्टि हुई, धन्यवाद।
वह OID walk करने पर: सबसे पुराने 1G optics वाले ports lane count के लिए बिल्कुल कुछ नहीं लौटाते, बाकी सब नए 1 के साथ जवाब देते हैं। तो null उन modules से आ रहा है जो मुझे विरासत में मिले, बिल्कुल जैसा बताया गया वैसा ही।
वह check रखने वाले build पर जाने के बाद, discovery सारे 7705s पर आखिर तक चलती है, transceivers हर एक single channel के साथ दिखते हैं, और optical sensors graph हो रहे हैं। router साइड पर कोई change नहीं, कोई port exclude नहीं।
अब जब discovery पूरी हो जाती है, तो दो चीज़ें उम्मीद करने वाली हैं।
Nokia gear पर DDM module EEPROM के एक capability flag से gate होता है। यह पूरे families में घर वाला approach है, और सबसे साफ तरीके से 7210 SAS interface guide में लिखा है: platform खुशी-खुशी उस module के लिए भी diagnostics print कर देगा जो वह flag कभी set ही नहीं करता, जबकि उसी paragraph में यह भी कहता है कि उसने उन numbers को validate या verify नहीं किया। तुम्हारे वाले से अलग box, पर logic वही: third-party optic से आते प्लॉजिबल RX/TX numbers इस बात का सबूत नहीं कि calibration सही है।
दूसरा आधा module खुद है। GLC-SX-MM का कोई A2h page नहीं है, तो किसी भी poller के पढ़ने के लिए कुछ है ही नहीं; GLC-SX-MMD का है, वह D diagnostics के लिए है। एक graph हमेशा के लिए flat और खाली, poller से पहले वह चेक कर लो।