جهاز Edgecore AS5114-48X على dentOS: وحدة SFP+ في المنفذ 18 تُعدّد بشكل جيد لكن onlpdump تبقى عند RX_LOS

RX_LOS بمفرده يقول فقط إن جهاز الاستقبال لا يرى ضوءًا كافيًا، لذا قبل أن تلوم الجهاز: ماذا يبلّغ الطرف البعيد؟ إذا كان المنفذ المقابل يُظهر DDM، اقرأ قدرة Tx الخاصة به وتأكد أن الليزر يعمل فعلاً وأن المنفذ ليس مُغلقًا. يستحق المعرفة أيضًا ما إذا كان كلا الطرفين نفس نوع الوصلة الضوئية ونمط الألياف - وحدة قصيرة المدى مقابل وحدة طويلة المدى، أو نوع ألياف خاطئ، يبدو تمامًا هكذا.

وهل جرّبت وحدة ثانية برقم قطعة مختلف في المنفذ 18، أم فقط نقلت هذه بين المنافذ؟

الطرف البعيد منفذ بسرعة 10G على مفتاح آخر، نفس الوصلات الضوئية قصيرة المدى على كلا الجانبين. ذلك المنفذ يرتبط بسعادة مع وحدة مختلفة عبر نفس كابل الباتش تمامًا، لذا الليزر المقابل حي والمسار الضوئي سليم من طرف إلى طرف. المنفذ 18 مفعّل إداريًا، وأحصل على نفس النتيجة تمامًا مع عكس الكابل.

الجزء المزعج هو ما يمكنني ملاحظته محليًا: onlpdump يعطيني الوجود بالإضافة إلى قناع بت الحالة، وهذا كل شيء. ليس لدي رقم Rx على جانب dentOS لمقارنته بالطرف البعيد، لذا أنا عالق عند «شيء ما لا يستقبل» دون معرفة أي طرف.

من العرض إلى السبب، بالترتيب الذي سأعمل به. الاكتشاف يُثبت مسار I2C/EEPROM وتوصيلات MAC، لا شيء آخر. سطر النواة عن inband/10gbase-r هو جانب المضيف يُهيّئ نفسه - لا يعني وصول فوتون واحد. مع تفعيل RX_LOS يبقى ثلاثة مشتبه بهم: ألياف مظلمة أو متقاطعة، طرف بعيد لا يُرسل، أو جهاز استقبال لا يعمل في هذه المنصة.

لقد ضغطت بقوة بالفعل على الأولين، لذا توقف عن جمع البتات واحصل على رقم. أي مفتاح يطبع تشخيصات رقمية سيفي بالغرض. على EXOS هو show ports <port> transceiver information، الذي يعطي درجة الحرارة، جهد التغذية، انحياز الليزر، قدرة Tx وRx ويُشير إلى كل قيمة خارج عتبات الوحدة، وdebug hal show optic port <port> يضيف المورّد ورقم القطعة والرقم التسلسلي والموصل وطول الموجة من EEPROM. تعقبت منفذًا ميتًا بسرعة 10G على جهاز X460-G2-24x-10G4 بهذه الطريقة ووجدت حوالي -26.78 dBm عند جهاز الاستقبال، وهو ما لن يلتزم به أي جهاز استقبال قصير أو طويل المدى بسرعة 10G.

إذا استطاع الطرف البعيد أن يعطيك قراءة Rx بينما تُرسل وحدتك، فستعرف على الأقل ما إذا كان الليزر الخاص به يعمل. ما يبقى بعد ذلك هو أن المنصة لا تُشغّل هذه القطعة بالتحديد.

نفس الجهاز هنا، وعلى هذه المنصة دعم الوحدات هو حسب القطعة، وليس حسب المعيار. على جهاز AS5114-48X لدينا، وحدة Avago AFBR-703SDZ-IN2 المراجعة G2.3 تعمل دون أي ضبط على الإطلاق - المنصة تُبلّغ عنها كـ Intel Corp مع الرقم التسلسلي AA1329A5UTA، وهو ما يُربك الناس للوهلة الأولى.

قطعتان لم تعملا لنا أبدًا في نفس المفتاح على نفس الألياف: Intel FTLX8571D3BCV-IT المراجعة A التي لديك، ووحدة OPNEXT TRS5020EN-S301. تم اكتشاف كلتيهما، وكلتاهما جلستا بالضبط مثل منفذك 18. استعر قطعة سليمة معروفة قبل أن تُمضي أمسية أخرى على البنية التحتية للألياف.

يستحق الدقة في تلك النقطة: RX_LOS هو ناتج فقدان الإشارة الخاص بالوحدة نفسها كما هو مُعرّف في SFF-8472، وطبقة المنصة تعرضه فقط كحالة 0x00000004. يتفعّل تحت عتبة LOS الخاصة بجهاز الاستقبال، لذا يخبرك «ضوء غير كافٍ» ولا يخبرك أبدًا لماذا. وهذا أيضًا سبب تعايش قراءة EEPROM النظيفة تمامًا مع مسار ضوئي ميت دون تناقض.

السبب الآخر للإصرار على رقم Rx حقيقي: التوهين يبدو مطابقًا لعدم التوافق من واجهة سطر الأوامر. كان لدى زميل منفذ Zyxel عند حوالي -25.69 dBm، وكان الحل هو كابل الباتش بالإضافة إلى لوحة توزيع أعاد أحدهم العمل بها، وليس الوحدة. إذا لم تستطع قراءة DDM على جانب dentOS، اقرأها من الطرف البعيد أو من مضيف - قناع بت وحده لن يحسم هذا.