بطاقة ConnectX-4 طراز MCX456A-ECAT لا تتصل بجهاز Cisco NCS عبر 100GBASE-LR4 بينما ينجح اختبار loopback على كلا الطرفين
ندير زوجاً من الرفوف يُسلِّم إلى جهاز Cisco NCS يواجه مشغّل اتصالات، وإحدى وصلات الخادم العلوية بسرعة 100G لم تعمل أبداً منذ التركيب. نفس النتيجة بعد نقل الخادم إلى خزانة أخرى بلوحة توزيع مختلفة، لذا توقفت عن معاملتها كحالة معزولة.
- خادم Supermicro، بطاقة NVIDIA/Mellanox ConnectX-4 طراز MCX456A-ECAT، كلا المنفذين متاح
- موديول QSFP28 عام من نوع 100GBASE-LR4، أحادي النمط، مدى 10 كم، واحد في كل طرف
- جهاز Cisco NCS في الطرف البعيد، ألياف مظلمة (dark fibre) بين الغرفتين
الجزء الذي يبقيني عالقاً: كل موديول ينجح في اختبار loopback على جهازه الخاص. مع توصيل الألياف مباشرة عائدة إلى نفس موديول QSFP28، تُبلغ البطاقة عن وصلة 100G نظيفة، ويفعل NCS الشيء نفسه في جانبه. ضع المسار الحقيقي بينهما ولا يوجد شيء.
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noما جرّبناه بالفعل:
- استبدلنا كلا الموديولين بموديولات احتياطية من نفس الدفعة، دون تغيير
- نقلنا الخادم وأعدنا التوصيل عبر لوحة مختلفة
- فتحنا حالة مع مورّد البطاقة، وكان الرد إشارة إلى قائمة الموديولات المعتمدة في ملاحظات إصدار البرنامج الثابت، وهو ما لا يفسّر سبب نجاح loopback
هل هناك شيء يخص LR4 على ConnectX-4 يسمح لها بالاتصال محلياً لكن أبداً عبر مسار حقيقي، أم أنني أطارد الطرف الخطأ من هذه المشكلة؟
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
هذا يبدو وكأنه مسار متسخ، وليس مشكلة توافق.
كل ما استبدلته حتى الآن يقع في الجانب الذي اختُبر بالفعل وثبتت سلامته، وهذا سبب عدم حدوث أي تغيير - المسار نفسه هو الشيء الوحيد الذي لم يُمس بعد. لذا اعمل على المسار:
قائمة الموديولات المعتمدة التي أُشير إليك هي تستحق نظرة، لكن موديولاً يعمل بشكل نظيف في loopback يُقاد بشكل صحيح بالفعل من البطاقة. قوائم التوافق تفسّر الموديولات التي تُرفض تماماً، وليس الموديولات التي تتصل محلياً ثم تموت عبر مسار.
إذا لم يُجدِ التنظيف نفعاً، فالخطوة التالية هي مصدر ضوء ومقياس طاقة على الألياف المظلمة، أو جهاز OTDR إذا استطعت استعارة واحد، قبل شراء بطاقة أخرى أو زوج آخر من الموديولات البصرية.
يثبت اختبار loopback فقط أن منفذاً واحداً يستطيع سماع نفسه - الليزر، المستقبل، إعدادات المعدل. لا يقول شيئاً عن الزجاج (الألياف) بين غرفتيك، وهذا هو الجزء الوحيد الذي لم تختبره. لذا قبل أن يُلام NIC مرة أخرى، احصل على أرقام من كلا الطرفين مع توصيل المسار الحقيقي: ما هي طاقة الاستقبال على منفذ NCS، وما هي على البطاقة؟ استقرار Rx تحت عتبة التحذير المنخفض مع وجود المسار هو المؤشر الكلاسيكي على الطرف البعيد أو المسار وليس على المنفذ المحلي.
على جانب Linux، يجب أن يعطيك
ethtool -mنفس القراءة، وإذا عاد بـCannot get module EEPROM information: Input/output errorفلا تقرأ ذلك على أنه موديول ميت - على mlx5 عادة ما يكون هذا وصولاً للموديول من جانب البرنامج الثابت، وستحصل على القيم رغم ذلك باستخدامmst startثمmst cable addثمmlxcables.كان التنظيف هو الحل. وضعنا مجهراً (scope) على الأوجه وكان كلا الموديولين وكلا كابلي التوصيل ملوَّثين؛ وكان الكابل المار عبر لوحة التوزيع بين الغرفتين هو الأسوأ من الاثنين. نظّفنا كل شيء في المسار، أعدنا التركيب، وعملت وصلة 100G مع NCS من المحاولة الأولى وبقيت تعمل منذ ذلك الحين.
منزعج قليلاً من نفسي لقضاء كل ذلك الوقت في زاوية التوافق بينما كانت نتيجة loopback تخبرني طوال الوقت أن الموديولات سليمة والمسار ليس كذلك. لمن يصل إلى هنا لاحقاً: loopback يثبت سلامة المنفذ، وليس الألياف.