جهاز CRS226 يُبلغ no-link وsfp-rx-lose yes على وصلة علوية SFP-10G-LR مُبرمَجة بترميز Cisco
تسلّمنا موقع تجميع (aggregation) صغيراً، وإحدى الوصلات العلوية بسرعة 10G لم تعمل منذ استبدال الموديول فيها. الموديول مُدرَج على أنه غير متوافق مع CRS226، لذا كان هذا أول مكان وقعت عليه الشبهة، لكن القراءات لا تبدو لي وكأنها موديول مرفوض.
- MikroTik CRS226 في موقع التجميع، الموديول في sfp-sfpplus1
- Fiberworks SFP-10G-LR، مُبرمَج بترميز Cisco
- زوج أحادي النمط (single-mode) إلى الموقع البعيد، موصَّل عبر لوحتي توزيع (panels) في الطريق
/interface ethernet monitor sfp-sfpplus1
status: no-link
sfp-rx-lose: yes
درجة الحرارة وجهد التغذية في نفس المخرج تظهر طبيعية تماماً، والموديول واضح أنه مكتشَف - هذه ليست قراءة منفذ فارغ.
ما تم إنجازه من جانبنا بالفعل:
- أعدت تركيب الموديول ونظّفت كلا الموصلين
- نقلته إلى منفذ SFP+ الآخر، نفس المخرج تماماً
- تحققت من تهيئة المنفذ، لا شيء مفروض ولا شيء معطَّل
إذن ما الأمر: هل يرفض CRS226 بصمت موديولاً مُبرمَجاً بترميز Cisco ويُبلغ عنه كـ no-link، أم أن sfp-rx-lose تعني ما أظن أنها تعنيه وينبغي أن أرسل أحداً إلى الطرف البعيد؟
Comments 5
مخرجك الخاص أجاب بالفعل على سؤال التوافق. موديول يرفضه المفتاح لن يُبلغ عن درجة الحرارة والجهد إطلاقاً - قراءة مراقبة كاملة تعني أن CRS226 قرأ الموديول ويتحدث معه بشكل جيد تماماً. أما
sfp-rx-lose: yesفهو مؤشر فقدان الإشارة (loss-of-signal) الخاص بالموديول نفسه: فهو لا يرى ضوءاً على ألياف الاستقبال. لا ضوء داخل، لا وصلة، أياً كان الترميز.إذن هذه مشكلة في البنية الفيزيائية (plant)، وليست مشكلة توافق. الترتيب الذي سأتبعه:
على سبيل الفائدة، نفس نوع هذا الموديول يعمل في جهاز CRS226 متصل بجهاز CCR هنا منذ أشهر، لذا فإن التوليفة نفسها ليست هي المشكلة.
ما الموجود في الطرف البعيد، وهل يُظهر ذلك الجانب منفذه كـ up؟ إذا كان جهاز الإرسال البعيد يعمل، فستتوقع بعض طاقة الاستقبال بدلاً من فقدان إشارة مطلق.
فحصان بسيطان قبل أن يذهب أحد إلى الموقع. بدّل بين الخيطين عند لوحة التوزيع لديك وانظر ما إذا كانت العلامة (flag) تبقى في مكانها. واطلب من الطرف البعيد قراءة موديوله الخاص: إذا أبلغ كلا الطرفين عن فقدان استقبال، فإن الزوج معطوب في مكان ما في المنتصف أو أن أحدهم وصّل الخيوط الخطأ في إحدى تلك اللوحات.
يستحق الأمر التمييز بين نمطي فشل أثناء وجودك هناك. عدم وجود ضوء إطلاقاً هو ما لديك، وهذا هو النمط السهل. النمط الأسوأ هو ضوء موجود بالكاد: إحدى وصلات الألياف العلوية هنا سجّلت إنذار انخفاض طاقة الاستقبال (Rx power low) عند -20.2 dBm مقابل عتبة -18.4 dBm، وتراكم لديها 46 ألف خطأ إدخال و42 ألف خطأ CRC بينما بقيت الوصلة up اسمياً. أمرا
show interface transceiver detailوshow interface counters errorsرويا هذه القصة.العمل الميداني نفسه في كلتا الحالتين - نظّف وافحص وجهي الطرفين، قِس TX وRX، ابحث عن خط طويل جداً، أو وصلة لحام (splice) سيئة، أو وصلة تصحيح (patch cord) رخيصة، واستبدل الموديول إذا بقيت المستويات منخفضة. لم أُثبت السبب الدقيق في حالتنا قط، فخذ هذا كتوجيه لا كحكم قاطع.
شيء آخر لقائمة تحقق الطرف البعيد: قد يموت جهاز الاستقبال من تلقاء نفسه دون وجود أي خطأ في الألياف.
لدى Cisco إشعار ميداني (field notice) برقم FN-72192 يغطي دفعة من موديولات QSFP-40G-LR4 - تُباع أيضاً باسم QSFP-40G-LR4-S وWSP-Q40GLR4L - خرجت من المصنع بكاشف الاستقبال منزاحاً قليلاً عن موضعه الصحيح. الإشعار يطال الموديولات التي يبدأ رقمها التسلسلي بـ ACW ويقع رمز تاريخها ضمن ACW2415xxxx-ACW2449xxxx: على هذه، يتدهور جانب الاستقبال وتسقط الوصلة. المنصّة المذكورة هي سلسلة ASR 900. المعالجة هي الاستبدال عند الفشل، لذا فهذا فحص للرقم التسلسلي وحالة دعم فني وليس شيئاً تُهيّئه بنفسك.
الجزء القابل للتعميم على وصلتك: الإنذار المبكر هو قيمة استقبال في بيانات DOM تنزلق بثبات نحو الأسفل بدلاً من أن تسقط فجأة. حجة جيدة لرسم بيانات DOM بيانياً على كل وصلة علوية بدلاً من قراءتها فقط بعد أن يكون شيء ما قد تعطّل بالفعل.
بخصوص الثقة بالقراءات - نعم في الغالب، لكن ليس بشكل أعمى. كانت هناك حالة متداولة لعصا Huawei GPON ONT جالسة في فتحة SFP+ من MikroTik، تُبلغ عن طاقة استقبال منخفضة جداً مع سرعات تنزيل عالقة تحت 20 ميغابت في الثانية على باقة أسرع بكثير، ولم يُثبت أحد قط ما إذا كانت القراءة أم الخط هو المتسبب في العطل. تُركت الحالة مفتوحة.
في زوج LR بسيط مثل زوجك، سآخذ مخرج المراقبة كما هو. أما في موديولات غريبة داخل منفذ SFP+، فيستحق الأمر قراءة ثانية من الطرف الآخر قبل التخطيط لإرسال فريق ميداني بشأنه.