Brocade G720 يُبقي كل منفذ SFP-DD بسرعة 64G في حالة Module_Invalid رغم تفعيل ترخيص DD PoD
ورثنا زوجاً من Connectrix DS-7720B (Brocade G720) لبنية شبكية جديدة، ولم أصل بعد إلى مرحلة توزيع المناطق (zoning)، لأن لا واحداً من منافذ الكثافة المزدوجة يرتفع. كل منفذ منها يقول نفس الشيء في switchshow:
Index Port Address Media Speed State Proto
====================================================
48 48 031800 dd -- Module_Invalid (Speed Mismatch / Incompatible SFP)
49 49 031900 dd -- Module_Invalid (Speed Mismatch / Incompatible SFP)
ما هو موجود في الرف:
- Connectrix DS-7720B / Brocade G720، نظام Fabric OS لا يزال على سلسلة 9.0.x التي وصل بها
- ترخيص Double Density Ports on Demand مثبَّت ويظهر مُفعَّلاً
- وحدات إرسال واستقبال بعلامة Brocade بسرعة 64G FC SFP-DD، الرقم 57-1000505-01
- كابلات تصحيح من نفس صندوق البصريات مباشرة من المصنع
قبل أن يقترح أحد الشيء البديهي: أعدت تركيب كل وحدة ونقلت وحدتين بين المنافذ، والعطل يبقى مع المنافذ لا أنه ينتقل مع الوحدات. ترخيص Double Density Ports on Demand مُفعَّل فعلاً وليس مجرد مطلوب، تحققت من ذلك مرتين. كابلات التصحيح استُبدلت، والأطراف نُظِّفت، دون فرق. المنافذ العادية على نفس الهيكل تنقل حركة المرور بكل سهولة، فهذا ليس محوّلاً معطلاً.
هل تسلّمنا دفعة سيئة من بصريات الكثافة المزدوجة، أم أن المحوّل يشطبها قبل أن ينظر فعلاً إلى ما في القفص؟
Comments 6
بصرياتك سليمة. برنامجك الثابت هو المشكلة.
وحدات 64G FC SFP-DD على G720 مدعومة ابتداءً من Fabric OS 9.1.0 فما فوق. على 9.0.x ليس لدى البرنامج الثابت أي مفهوم عن هذا الشكل الفيزيائي إطلاقاً، لذا لا يستطيع التعرّف على ما يوجد في القفص ويلجأ إلى إعلانه غير متوافق - وهذا بالضبط ما تراه Module_Invalid مع Speed Mismatch / Incompatible SFP على كل منفذ كثافة مزدوجة. عملك على الطاولة يقول نفس الشيء من الاتجاه الآخر: بصريات عادية تضيء في نفس المنفذ الذي يرفض وحدة dd، والهيكل الثاني يتصرف بنفس الطريقة تماماً لأنه يعمل بنفس البرنامج الثابت.
القطعة التي لديك، 57-1000505-01، مُدرجة في مصفوفة دعم وحدات الإرسال والاستقبال (Brocade Transceiver Support Matrix)، وهذه المصفوفة هي المكان الذي يُدوَّن فيه الحد الأدنى للبرنامج الثابت لكل منصة. بالنسبة لـG720 تبدأ هذه المدخلة عند 9.1.0. انتقل إلى 9.1.0 أو أحدث وسترتفع تلك المنافذ بالبصريات الموجودة فيها بالفعل.
نفس القصة تنطبق على تلك اللوحة (blade) في الصندوق. كل منصة من الجيل السابع تحمل حداً أدنى خاصاً بها في المصفوفة - G730 (DS-7730B)، و7850 (MP-7850B)، وFC64-64 من بينها - لذا ابحث عن كل واحدة قبل نقل بصريات الكثافة المزدوجة إليها، وإلا فستخسر بعد ظهر يوم آخر على الجهاز التالي.
مهما فعلت غير ذلك، لا تُعِد الوحدات.
توقف عن أوراق إرجاع البضاعة (RMA)، لأن دفعة كاملة من بصريات معطوبة ليست ما يبدو عليه الأمر من هنا. Module_Invalid مع وجود dd فعلاً في عمود الوسط يعني أن المحوّل حصل على شيء من القفص ولم يعجبه ما قرأه. الوحدة المعطوبة فعلاً عادة لا تصل إلى هذا الحد - كنت ستنظر إلى حالة no-module بدلاً من ذلك.
ثلاثة أشياء ستُضيّق الاحتمالات ولا تكلفك شيئاً:
وأبقِ الترخيص خارج تفكيرك حالياً. Ports on Demand يفتح المنافذ؛ ولا يُعلِّم البرنامج الثابت عن شكل فيزيائي لم يقابله من قبل.
قرار جيد باستعارة البصريات. سحبت وحدة Brocade عاملة من أحد المنافذ العادية، وضعتها في المنفذ 48، واتصلت فوراً كمنفذ F-Port. أعدت وحدة SFP-DD بسرعة 64G إلى نفس المنفذ فعادت Module_Invalid خلال ثانية أو ثانيتين. إذن القفص حي، والترخيص يؤدي عمله، والمنفذ نفسه سليم - المشكلة فقط في وحدات الكثافة المزدوجة التي لا يقبلها المحوّل.
كلا المحوّلين، نعم. المحوّل الثاني DS-7720B لا يزال في صندوقه غالباً، لكنني وضعت وحدتين من dd فيه على الطاولة وحصلت على نفس السطر بالضبط، إذن الأمر ليس هيكلاً واحداً به عطل.
الجيل السابع في أماكن أخرى: لا شيء في الإنتاج بعد، لكن هناك لوحة FC64-64 في صندوق تنتظر فتحة في مدير (director)، واشتُريت خصيصاً لهذه البصريات. إن كانت ستعضّ هناك أيضاً، أفضّل أن أعرف الآن بدلاً من أثناء نافذة الترحيل.
مورّد مختلف، نفس شكل الفخ. أنشرها هنا لعلها توفّر على شخص آخر بعد ظهر يوم كامل من سحب الوحدات من الأقفاص.
Dell S5248F-ON، بناء SONiC رئيسي. لا واحد من منافذ SFP28 عمل. كل مصباح منفذ ثابت، وshow interface transceiver presence لم يُدرج أي وحدة إرسال واستقبال إطلاقاً، مع بصريات سليمة تماماً في الأقفاص.
لا شيء من ذلك كان بصرياً. حاوية مراقب المنصة (platform monitor) كانت متوقفة: pmon لم يكن يعمل، ولا pcied ولا xcvrd ولا psud. xcvrd هي العملية التي تتحدث بروتوكول I2C مع الوحدات، فبموتها لم يكن أحد يقرأ EEPROM إطلاقاً، وكانت واجهة سطر الأوامر تُبلغ بصدق عمّا تعرفه، وهو لا شيء. docker ps وshow system-health detail أخبراني القصة كاملة خلال دقيقة تقريباً - بعد أن كنت قد أمضيت نصف يوم أُبدّل الوحدات.
نفس فئة المشكلة على Z9264F، حيث انهار مُنشئ Sfp الخاص بإضافة المنصة (platform plugin) بخطأ AttributeError: 'Sfp' object has no attribute 'port_type' وأسقط معه خدمة determine-reboot-cause.service عند الإقلاع. عندما تسيء فئة كاملة من المنافذ التصرف بنفس الطريقة تماماً، البصريات هي تقريباً آخر ما ينبغي الاشتباه فيه أولاً.
النصف الآخر من هذا غير برّاق، وهو المكان الذي يذهب إليه الوقت فعلياً. قفزة في Fabric OS على محوّل لا شيء خلفه بعد تبقى نافذة تغيير (change window) وليست شيئاً تفعله بين اجتماعين، لذا حدد أولاً ما الذي يجب أن يتحرك معها في بقية البنية واحجز التوقف بشكل صحيح.
بما أن FC64-64 لا تزال في صندوقها: ضعها على 9.1.0 أو أحدث قبل أن ترى بصريات كثافة مزدوجة إطلاقاً. وإلا فستكرر هذا الموضوع في مدير (director) بدلاً من محوّل طرفي، وأمام جمهور.
شيء عملي آخر. تواصل مع موردك قبل أن يسجّل RMA. تلك الوحدات تُعرِّف نفسها بشكل صحيح تماماً، المضيف فقط ليس لديه مدخلة في الجدول بعد. إن قَبِل المورّد إعادتها كمعطوبة فستنتظر ثلاثة أسابيع لدفعة بديلة تتصرف بنفس الطريقة تماماً، وستضطر رغم ذلك للترقية.
تأكد الأمر، وكانت المشكلة في البرنامج الثابت.
انتقل كلا المحوّلين إلى 9.1.0 في نافذة نهاية الأسبوع، وعند إعادة التشغيل خرج كل منفذ كثافة مزدوجة من Module_Invalid واتصل بسرعة 64G بنفس بصريات 57-1000505-01 التي كانت موجودة فيها طوال الوقت. لم يُعَد تركيب شيء، ولم يُستبدل شيء، ولم يُعَد توصيل أي كابل.
تبيّن أن الترخيص كان الأثر المضلِّل (red herring) الذي كنت أطارده - مُفعَّل بشكل صحيح منذ البداية، لكنه ببساطة لم يستطع فعل شيء مفيد على 9.0.x. اللوحة تنتقل إلى 9.1.0 قبل أن تقترب من أي فتحة مدير، وكتبت ذلك على الصندوق الذي توجد فيه. وفّر علينا ذلك عملية RMA ومحادثة محرجة إلى حد ما مع المورّد.