كيفية سحب بيانات وحدة uplink ومستويات ONU على ZXA10 C320 - عبر CLI أم عبر SNMP
لدي عقدة تعمل بجهاز ZTE ZXA10 C320، بمنفذ uplink بسرعة 10G. أراقب المستويات والحالة يدويًا من الطرفية، لكنني أريد إدخال كل شيء في نظام المراقبة حتى لا أضطر للدخول إلى CLI مع كل شكوى من مشترك.
- OLT: ZTE ZXA10 C320
- uplink: وحدة SFP+ في xgei_1/21/1
- المشتركون على gpon-onu_1/1/1:1 وما يليها عبر الفروع
بخصوص وحدة uplink وجدت بعض المعلومات، ويُظهر الناتج هذا الأمر:
show int optical-module-info xgei_1/21/1بعد ذلك أصطدم بثلاثة أمور:
- أي أمر يسحب المستوى لجهاز ONU محدد، بدلاً من تحليل الناتج لكل الفرع
- هل يوجد كائن SNMP بنفس قدرة الاستقبال حتى لا أضطر لتحليل CLI بسكريبت؛ لم أجد قالبًا جاهزًا لـ C320 في المراقبة
- إلى أي مدى يمكن الوثوق بمستوى الاستقبال أصلاً: على أحد وصلات uplink الرقم جيد لكن أخطاء CRC على الواجهة تتراكم ببطء في نفس الوقت
من يسحب هذه البيانات من C320 بشكل مستمر - على ماذا استقررتم، CLI أم SNMP، وما هي OID المستخدمة؟
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 4
وضّح ما الذي تحتاجه بالضبط في المراقبة. جرد الوحدة (المورّد، رقم القطعة، الرقم التسلسلي) والقدرة بشكل ديناميكي أمران مختلفان: الأول يكفي سحبه مرة يوميًا وحفظه كحقيقة ثابتة، والثاني منطقي أن يُستطلع بانتظام ويُرسم كرسم بياني.
وسؤال ثانٍ، أهم: هل نظرت في أخطاء CRC على uplink بشكل مقصود أم لاحظتها عرضًا؟ إذا كان العداد يزداد فعلاً، فمستوى الاستقبال ليس المشتبه به الرئيسي هنا، ويجب البدء ليس برسم الرسوم البيانية بل بهذه الواجهة.
بخصوص uplink، كل ما تحتاجه بالفعل يعطيك إياه نفس الأمر الذي وجدته:
في الناتج مباشرة اسم المورّد ورقم القطعة والرقم التسلسلي ونوع الوحدة (مثلاً 10GBASE-LR)، طول الموجة 1310 نانومتر، Rx وTx بوحدة dBm، تيار الانحياز، سرعة الليزر ودرجة الحرارة. بالإضافة إلى عتبات الإنذار للقدرة والتيار والجهد ودرجة الحرارة في نفس المكان - لا داعي للذهاب إلى الجرد بشكل منفصل.
بخصوص المشتركين، انظر إلى التوهين لجهاز ONU محدد:
للمراقبة، قدرة الاستقبال على OLT موجودة على .1.3.6.1.4.1.3902.1015.1010.11.2.1.2:
يجب قسمة القيمة الخام على 1000 حتمًا، وإلا ستحصل على آلاف غير مفهومة بدلاً من dBm. يقع في هذا الخطأ تقريبًا كل من يرسم رسمًا بيانيًا لأول مرة باستخدام هذا OID.
وبخصوص نقطتك الثالثة: قبل استخلاص أي استنتاجات بناءً على المستوى، انظر إلى عدادات CRC على uplink. مستوى Rx طبيعي بحد ذاته لا ينفي موصلاً متسخًا أو مسارًا تالفًا.
القسمة على 1000 هي بالضبط ما كان ناقصًا. كان لدي على الرسم البياني آلاف بدلاً من dBm، وطوال هذا الوقت كنت أظن أنني أخذت الكائن الخاطئ.
بخصوص uplink، تطابقت الصورة: الوحدة 10GBASE-LR، 1310 نانومتر، مستوى الاستقبال طبيعي، بينما CRC تتراكم في نفس الوقت. ذهبت إلى صندوق التوزيع - تبيّن أن الموصل متسخ، وبعد التنظيف توقف العداد. إذن نصيحة النظر إلى CRC قبل المستوى كانت في محلها.
المستويات لجهاز ONU محدد تُسحب بالأمر، سأضع عليها مراقبة.
بخصوص المراقبة: لا تنتظر قالبًا جاهزًا. تغطية C320 من الصندوق جزئية - منافذ GPON وضوئيات ONU وطول الخط لن تظهر من تلقاء نفسها. في LibreNMS (الإصدار 25.8.0-dev) لم يظهر دعم مناسب لهذه العائلة على الإطلاق: لا OID جاهزة، ولا طريقة موثّقة نشرها أحد. أي أن الطريق واحد - كائناتك الخاصة وقالبك الخاص، وأنت بالفعل تسير في هذا الاتجاه.
وفي نفس الوقت ضع في اعتبارك أن هذا يُسمّى بشكل مختلف على عتاد مختلف. على Cisco ISR 4451 لا يوجد الأمر المعتاد من الواجهة، ويُقدَّم DDM عبر
show hw-module subslot 0/0 transceiver 0 status، وعلى FortiGate هوget system interface transceiver. إذا كنت تجمع أداة استطلاع موحدة لأسطول من مورّدين مختلفين، فمن الأسهل سحب كل شيء عبر SNMP، والاحتفاظ بـ CLI لتحليل شكوى محددة.