محوّل QSA في فتحة SONiC QSFP28: الوصلة الضوئية بسرعة 10G ترتبط لكن لا تُبلّغ عن DDM
نُعيد استخدام كومة من الوصلات الضوئية بسرعة 10G على مفتاح whitebox يعمل بنظام SONiC، لذا زُوّدت بضع فتحات QSFP28 بمحوّلات من نوع QSA (10GTek QSA-100A) تحمل وحدات SFP+ عادية بسرعة 10G. ميكانيكيًا وكهربائيًا هذا سليم. جانب الإدارة هو حيث ينهار الأمر.
- المفتاح: whitebox بارتفاع 1U، SONiC مبني لتلك المنصة
- المحوّلات: 10GTek QSA-100A، من فتحة QSFP28 إلى SFP+
- الوصلات الضوئية: وحدات SFP+ بسرعة 10G مسحوبة من مفتاح وصول تم إيقافه
- نفس الوصلات الضوئية تُقرأ بشكل طبيعي في فتحة SFP+ أصلية على جهاز آخر
ما أراه على المنافذ المُحوَّلة:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portما تم تجربته حتى الآن:
- استبدلت بمحوّل ثانٍ ووصلة ضوئية ثانية، نفس السلوك
- نقلت الزوج إلى فتحة QSFP28 مختلفة، نفس النتيجة
- تحققت من أن الوصلات الضوئية تُبلّغ عن تشخيصات كاملة في منفذ SFP+ أصلي في مكان آخر
هل بيانات التشخيص المفقودة هذه شيء لا يستطيع محوّل سلبي حمله ببساطة، أم أن الأمر في برنامج المفتاح؟ وإذا كان برمجيًا، أين ينتمي الإصلاح: طبقة المنصة أم كود الوصلة الضوئية العام؟
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 7
قبل أن يحفر أحد في كود المنصة، سؤال واحد يفصل هذا إلى نصفين. ضع وحدة QSFP28 أصلية في نفس الفتحة: هل تحصل على تشخيصات منها، أم أن DDM ميت على ذلك المنفذ بغض النظر عمّا تُدخله؟
إذا قرأت القطعة الأصلية بشكل جيد، فالفتحة ومسار I2C سليمان والأمر كله يعود إلى كيفية تفسير برنامج تشغيل المنفذ لما يصل عبر المحوّل. إذا عادت القطعة الأصلية فارغة أيضًا، توقف عن قراءة بقية الموضوع، لديك عطل مختلف ولا علاقة له بالمحوّلات.
فرق معروف ومملّ نوعًا ما في واجهة الإدارة، والمحوّل ليس الجاني هنا.
على جانب SFP يوجد عنوانا I2C فعّالان: بيانات الهوية تعيش عند 0x50، وخريطة التشخيص عند 0x51. القطعة من نوع QSFP تحتفظ بكل شيء تحت 0x50 وتصل إلى الباقي بتبديل الصفحات. لذا برنامج تشغيل قيل له إن الفتحة QSFP يبحث عن صفحات عند عنوان واحد فقط ولا يسأل 0x51 عن أي شيء أبدًا. الهوية تعود معقولة بما يكفي ليعمل المنفذ، لكن التشخيصات ببساطة لا تُحل أبدًا، وهذا بالضبط شكل ما نشرته.
الإصلاح ينتمي إلى طبقة المنصة، وليس إلى الوصلة الضوئية ولا إلى المحوّل. كل منصة تشحن تطبيقها الخاص لـ SfpUtil؛ في منصتك يجب إعلان ذلك المنفذ كفتحة SFP بدلاً من QSFP. حتى يفعل أحد ذلك، ستبقى DDM/DOM فارغة على المنافذ المُحوَّلة. بعد ذلك تُقرأ الوحدة بنفس الطريقة التي ستُقرأ بها في فتحة SFP+ أصلية.
رابط حي بدون أي شيء وراءه في التشخيصات هو ما يبدو عليه برنامج خاطئ على هذه المنافذ. إنه ليس ما تبدو عليه وصلة ضوئية هامشية.
يستحق تسمية المعايير، لأن الفصل يصبح واضحًا حينها. جانب SFP هو SFF-8472، حيث تعيش التشخيصات في خريطة ذاكرة خاصة بها يُصل إليها عند العنوان الثاني. QSFP وQSFP28 تتبع SFF-8636، والقطع الأحدث CMIS، حيث يعتمد كل شيء على عنوان واحد خلف اختيار صفحة.
المحوّل لا يستطيع ربط ذلك. إنه جزء ميكانيكي وكهربائي سلبي، أسلاك الإدارة تمر عبره مباشرة ولا شيء يترجمها في الطريق. لذا يجب إخبار المضيف بأي من نموذجي الذاكرة ينطبق قبل أن يقرأ بايتًا واحدًا، والمحوّل ليس لديه طريقة لإخباره.
للمقارنة، نفس فئة المشكلة على عتاد Dell ONIE تُسبب مشاكل أكبر. محوّل 407-BBRO QSA مع وحدة 407-BBOU 10GBASE-SR SFP+ بداخله (SFP-10GSR-85)، في منافذ 40G لجهاز S4048-ON وفي أي منفذ لجهاز S6010-ON، كلاهما يعمل بنظام OpenSwitch OPX 3.1 dev2:
يُعرّف opx-ethtool الوسيط بشكل صحيح، ويُعلّم الوصلة الضوئية كمفعّلة ومؤهّلة، وحالة الإدارة up، والسرعات المدعومة 1000 و10000 و40000 ميجابت في الثانية، والمنفذ لا يعمل أبدًا مع ذلك، بغض النظر عن السرعة أو الازدواجية أو التفاوض التلقائي المُعد، بما في ذلك الإعدادات الافتراضية. فتح أحدهم طلب تحسين على مستودع OPX platform-config، من فضلكم اجعلوا QSA يعمل هنا، ولم يرد أحد أبدًا. لا يزال مفتوحًا.
ليس قفل مورّد وليست وصلة ضوئية سيئة. تلك الفتحة ببساطة لا يضعها نظام تشغيل الشبكة في وضع المحوّل أبدًا، ولا أي توليفة من إعدادات الواجهة ستفعل ذلك لك.
ذو صلة، لكن الرجاء عدم دمج الحالتين معًا. ما لدى المنشور الأصلي هو رابط يعمل مع تشخيصات مفقودة: مسار البيانات سليم، فقط قراءة الإدارة خاطئة، وتعديل SfpUtil الخاص بالمنصة يُصلحه. حالة Dell هي منفذ لا يعمل أبدًا، لأن ملف تعريف المنفذ لتلك الفتحة لا يُطبَّق أصلاً. هذا يقع في طبقة أسفل ويحتاج إصلاحه الخاص.
شخص يطابق الأعراض على عجل قد يُمضي يومًا كاملاً في إعادة كتابة كود الوصلة الضوئية بينما منفذه معطل لسبب غير ذي صلة على الإطلاق.
نكهة أخرى من "المحوّل ميزة برمجية" وليس ميكانيكية. على جهاز Z9264F-ON تحت OS10 10.5.2.7، استخدام محوّلات QSA28 لوسيط SFP+ بسرعة 10G يعني وضع المنفذ في نفس ملف تعريف مجموعة المنافذ الذي يستخدمه كابل تقسيم 4×10G:
ملفات تعريف مجموعة المنافذ على تلك المنصة تعمل على أزواج من منافذ QSFP28، لذا تطبيقها يُعطّل المنفذ الشريك لكل زوج. QSA28 هو واجهة واحدة وأنت لا تزال تدفع ثمنًا بشكل تقسيم: 64 منفذًا قابلاً للاستخدام تصبح 32. لا أدلة مستخدم OS10 ولا ورقة مواصفات وصلات Dell الضوئية توثّق نمط QSA لمنفذ واحد.
إذا كنت بحاجة إلى الكثير من 10G الأصلي على ذلك الجهاز، خطط للخسارة 2:1 مسبقًا أو ضع مفتاح 10G منفصل في الرف.
قبل أن يطلب أحد صينية من هذه الأشياء، سأضع فحصين في القائمة. هل يُعلن نظام تشغيل الشبكة دعم QSA لتلك المنصة بالتحديد أصلاً، وإذا كان يفعل، ماذا يكلفك تفعيله: منافذ، تشخيصات، أو ملف تعريف يسحب الفتحة المجاورة معه إلى الأسفل. الملاءمة ليست المشكلة أبدًا، كل واحد من هذه المحوّلات يدخل في الفتحة دون شكوى.
الحالات في هذا الموضوع تختلف فقط في إلى أي مدى يذهب البرنامج. على SONiC تحصل على شيء يمكنك إصلاحه بنفسك، أعلن المنفذ كـ SFP وتعود التشخيصات. على منصات Dell أعلاه أنت تنتظر كود منصة شخص آخر، وتبديل المحوّلات أو الوصلات الضوئية لن يحرك ذلك على الإطلاق.