أجهزة ZXA10 OLT في LibreNMS: لا قراءة dBm لوحدات الإرسال والاستقبال في صفحات المنافذ، واختفت مستشعرات المروحة ومزود الطاقة
نراقب أسطولًا مختلطًا من أجهزة ZTE ZXA10 OLT عبر LibreNMS وهناك مشكلتان. أظن أنهما غير مرتبطتين، لكنني لست متأكدًا.
- ZTE ZXA10 C300 على V2.1.0، ما زال يعمل في نقطة وجود قديمة
- ZTE ZXA10 C620 على V2.0.30، بالإضافة إلى C650 وC650E
- جهاز ZTE ZXA10 C320 واحد كان يعمل بشكل طبيعي سابقًا
- روابط uplink من نوع SFP وSFP+، بطاقات GPON تحتها
المشكلة الأولى: صفحات المنافذ لا تحتوي على أي مستشعرات إرسال واستقبال إطلاقًا. لا طاقة استقبال أو إرسال بوحدة dBm، ولا درجة حرارة الوحدة، ولا جهد التغذية، ولا تيار انحياز الليزر (bias current). هذه هي الأرقام التي أريدها لرصد موصل متسخ قبل أن يبدأ المشتركون بالاتصال.
المشكلة الثانية: مستشعرات الحالة التي كانت تعمل على C320، المراوح ومزودات الطاقة وحالة البطاقة، اختفت بصمت بعد إعادة اكتشاف (rediscovery). لا خطأ في السجل، لا شيء فشل، ببساطة لم تعد موجودة على الجهاز.
عند فحص الأجهزة يدويًا، البيانات البصرية موجودة بوضوح في MIB في مكان ما، لكن OID يستجيب على منصة واحدة ولا يعيد شيئًا على أخرى:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1ما جُرّب حتى الآن:
- إعادة اكتشاف واستطلاع كامل لكل جهاز
- مقارنة ما يرد به C650 مقابل ما يرد به C300 على نفس OID
- التحقق مما إذا كانت المقابس الفارغة هي سبب توقف الاكتشاف
أين تعيش القراءات البصرية فعليًا في عائلة ZXA10، وما الذي يجعل مستشعر حالة يختفي عند الاكتشاف دون تسجيل أي شيء؟
Comments 5
كلتا المشكلتين معروفتان، وكما خمّنت هما غير مرتبطتين.
أي جدول بصري تحصل عليه يعتمد على المنصة، ولا يتعايش الاثنان أبدًا على نفس الجهاز. جهاز C300 الأقدم، الذي اختُبر هنا مقابل V2.1.0، يعرض zxAnOpticalModuleMonTable:
C620 على V2.0.30، وC650 وC650E يعرضون بدلًا من ذلك zxAnOpticalModuleInfoTable:
كلا الجدولين يمنحك نفس القراءات الأربع: طاقة الاستقبال والإرسال بوحدة dBm، ودرجة حرارة الوحدة، وجهد التغذية، وتيار انحياز الليزر. القيم الخام تحتاج إلى معامل تحجيم 0.001. يحتاج الأمر أيضًا إلى تصفية قيمتين حارستين (sentinels)، وإلا فإن كل مقبس فارغ في الهيكل سينذرك: منفذ غير مدعوم أو مقبس غير مأهول يجيب بـ2147483647، ومنفذ مظلم يجيب بـ-80000. حضور البطاقة لا ينتمي إطلاقًا إلى الاستطلاع البصري، فهذا مستشعر حالة تشغيلية منفصل يتخطى الفتحات غير المأهولة.
اختفاء المراوح ومزودات الطاقة وحالة البطاقة لديك مشكلة مختلفة تمامًا. كانت إدخالات الحالة في ملف YAML الخاص بالمنصة تفتقد المفتاح value:، وبدونه ينتهي الاكتشاف بقراءة اسم الجدول وكأنه عمود، ولا يجد شيئًا صالحًا للاستخدام ويُسقط المستشعر بصمت، دون أي خطأ في أي مكان، وهذا سبب ملاحظتك له فقط كغياب. إعادة المفتاح استعادت ستة مستشعرات على منصة اختبار C320 هنا.
تحذير عادل قبل أن تخطط بناءً عليه: هذا يسير ضمن تغيير ما زال مفتوحًا وليس مدمجًا بعد، وقد قلّصت المراجعة بالفعل مراقبة أخطاء إيثرنت منه باعتبارها خارج النطاق. تعامل معه كترقيعة تحملها بنفسك، لا كإصلاح تنتظره.
أرنا sysDescr الذي يبلغه كل من تلك الأجهزة. C300 وC320 وC620 وC650 وC650E ليست عائلة واحدة فيما يخص MIB البصري، لذا فإن OID يستجيب على بعضها ويصمت على الباقي هو أمر متوقع وليس عطلًا.
انشر نهاية استطلاع (walk) من الجهازين الأكثر اختلافًا، C300 وأحد أجهزة C650، على نفس OID الذي جربته بالفعل. إذا استجاب أحدهما وكان الآخر فارغًا، فهذه هي القصة كاملة والإصلاح خاص بكل منصة.
كذلك أبقِ مشكلتيك منفصلتين. مستشعرات المروحة ومزود الطاقة المفقودة هي مسألة تعريف اكتشاف ولا علاقة لها بأي جدول بصري ينفذه OLT.
أؤكد نفس الفجوة من جانب آخر. سألت عن نفس العائلة على 25.8.0-dev: جهاز C320 GPON OLT، وما كنت أبحث عنه هو رسم بياني لمنافذ GPON في كلا الطرفين، على OLT وعلى ONUs - مستويات طاقة الاستقبال والإرسال، ومدة قياس كل رابط، والاستخدام لكل منفذ - بالإضافة إلى ما إذا كان يوجد بالفعل قالب (template) لهذه العائلة في مكان ما.
أُغلق الطلب دون أن ينشر أحد OID أو استطلاعًا أو طريقة، لذا فكل ما يوثقه هو أن التغطية الجاهزة لعائلة C320 جزئية. بأثر رجعي كان عليّ إرفاق استطلاع (walk) بالطلب. إذا كنت تبني هذا على أي حال، مستويات الطاقة البصرية لـONU هي الجزء الذي لم يفعله أحد وسيستخدمه كثيرون منا.
هذا يطابق ما يفعله الأسطول. يجيب C300 على .1.3.6.1.4.1.3902.1015.3.1.13.1 ولا يعيد شيئًا على OID الآخر، وC620 وC650 على العكس، وC650E يتصرف مثل C650.
تعود القيم كأعداد صحيحة تحتاج إلى معامل تحجيم 0.001، تمامًا كما وُصف. الأرقام التي بدت كخردة في البداية أصبحت منطقية الآن: 2147483647 على المقابس التي لم نُملأها أبدًا، و-80000 على منفذين حيث الطرف البعيد مطفأ. كلا القيمتين الحارستين حقيقيتان هنا، لذا فإن أي شخص يكتب عتبات (thresholds) بناءً على الأرقام الخام سيحصل على قائمة تنبيهات صاخبة جدًا.
تحققت أيضًا من ملف YAML الخاص بالمنصة والمفتاح value: مفقود لدينا أيضًا. سأحمله محليًا بما أن التغيير ما زال مفتوحًا. تقسيم المشكلتين هو الجزء الذي أخطأت فيه منذ البداية.
شيء واحد يستحق تذكره أثناء بناء هذا: بيانات DOM هي مجموعة جزئية في كل مكان، وليس فقط على ZTE.
في SONiC تُقرأ ذاكرة EEPROM الخاصة بوحدة CISCO-AVAGO AFBR-89CDDZ-CS3 من نوع QSFP28 دون مشاكل، وتُملأ TRANSCEIVER_INFO وTRANSCEIVER_DOM_SENSOR وTRANSCEIVER_STATUS جميعها بالهوية بالإضافة إلى درجة الحرارة والجهد والانحياز والطاقة لكل مسار (lane)، لكن مجموعة التحكم والحالة غائبة ببساطة: get_rx_los وget_tx_fault وget_tx_disable وget_lpmode وget_power_override تعيد لا شيء في عرض قاعدة البيانات، لذا إذا احتجت تلك البتات اذهب واسأل واجهة برمجة تطبيقات المنصة (platform API) عنها بنفسك.
نفس الدرس من جانب جدار الحماية. في PAN-OS، يطبع show transceiver-detail all كتلة التشخيص، وأول حقل تقرأه هو diagnostic-monitor. إذا قال No، فإن الوحدة لا تنفذ المراقبة البصرية الرقمية (DOM) وتعود كل قيمة N/A. لا شيء معطوب هناك، فقط لا يوجد ما يُقرأ. يستحق ترميز هذا التمييز في نظام التنبيهات لديك حتى لا تبدو وحدة بلا DOM كمنفذ ميت.