Lenovo RackSwitch G8124E يرفض وحدة SFP+ عامة من نوع 10G SR برسالة UNAPPROVED - SR SFP+ is DISABLED
سحبنا زوجاً من G8124E من رف خرج من الخدمة وأنا أعيد بناءهما كطبقة تجميع (aggregation) لبيئة اختبار داخلية. ميزانية البصريات ذات العلامة التجارية صفر، لذا كل شيء يُركَّب بوحدات 10G SR عامة من النوع الذي نُشغّله بالفعل في أماكن أخرى.
- Lenovo RackSwitch G8124E، هيكل بعلامة IBM سابقاً
- SFP+ من نوع 10G SR عامة، LC مزدوج، من نفس الدفعة التي تعمل في أعلى الرف لدينا في الإنتاج
- وصلة OM3 إلى بطاقة شبكة خادم ترتبط بسرعة 10G بنفس نوع الوحدة تماماً
المنفذ يحيا للحظة ثم يُغلقه المحوّل:
UNAPPROVED - SR SFP+ is DISABLED
بعد ذلك لا يتأسس الرابط أبداً ويبقى المنفذ معطّلاً.
ما جربته بالفعل:
- نقلت الوحدة عبر أربعة أقفاص مختلفة، نفس الرسالة في كل مرة
- بدّلت بوحدة ثانية من نفس الدفعة وثالثة من مورّد آخر
- راجعت إعداد الواجهة بحثاً عن شيء مثل مفتاح allow-unsupported ولم أجد شيئاً
هل هناك طريقة لجعل هذا الجهاز يقبل بصريات من طرف ثالث، أم أن فحص الموافقة شيء لا يمكن تحقيقه إلا بوحدات مُشفّرة لـLenovo؟
Comments 5
قبل أن يُعطيك أحد أمراً، ماذا يُظهر
show version؟ في هذه العائلة العلاج ليس أمراً واحداً، بل ينقسم حسب سلسلة الشيفرة: ما تفعله على صورة 7.x ليس ما تفعله على 8.x، لذا يجب تحديد الإصدار أولاً.أيضاً قل ما إذا كانت الوحدات عامة بحتة أم تحمل سلسلة مورّد معروفة في EEPROM. البرنامج الثابت يُقيّم كل وحدة حسب تلك السلسلة، ويحصل أشخاص لديهم SFP+ مُشفّرة لـIntel على نفس المحوّل بالضبط على تحذير الوحدة غير المعتمدة أيضاً، لذا الرسالة وحدها لا تخبرك كثيراً عن البصريات نفسها.
show versionيضعها على صورة 7.x، إذن السلسلة الأقدم وليست الحالية.الوحدات عامة بحتة، لا يوجد فيها تشفير Intel أو Cisco، تُعرِّف نفسها بأنها من الشركة المصنّعة الأصلية (OEM) التي صنعتها. وضعت أيضاً الوحدة الثالثة في IBM RackSwitch G8124 الواقف بجانبه وحصلت على نفس السلوك هناك، إذن هذا ليس قفصاً سيئاً واحداً أو بصريات سيئة واحدة.
على السلاسل الأقدم يوجد متغير في محمّل الإقلاع (boot loader) يُطفئ فحص الموافقة. موصوف لـ5.x و6.x و7.x و8.3.x فأقل، لذا جهاز 7.x يقع ضمن النطاق.
تحتاج طرفية تسلسلية (serial console) لهذا، منفذ mini-USB RS232، وليس الشبكة. أعد تحميل المحوّل واضغط مع الاستمرار Shift+M خلال اختبار الذاكرة حتى يعطيك محمّل الإقلاع موجّه
=>، ثم:القيمة حساسة لحالة الأحرف،
Overrideبحرف O كبير. شغّلprintenvقبلbootحتى ترى فعلاً أن المتغير قد حُفظ. بمجرد أن ينتهي المحوّل من الإقلاع يتوقف عن تعطيل وحدات SFP+ غير المعتمدة وترتفع المنافذ فحسب.تنبيهان. هذا إجراء مختبري وطارئ، Lenovo لا تدعم البصريات من طرف ثالث ولا شيء هنا رسمي. وابتعد عن البصريات ثنائية المعدل على هذه الأجهزة الأقدم، فهي تسبب مشاكل حتى بعد إزالة الفحص من الطريق.
نفس القصة عبر خط محوّلات Lenovo بأكمله، وليس فقط G8124E. لدي هنا G8272 يُقيّم وحدة Cisco-Finisar
SFP-10G-LR-Sبأنها غير معتمدة (Unapproved)، ويُظهر المنفذ كمعطَّل (Disabled) ويترك الرابط ساقطاً. بصريات Cisco أصلية، ببساطة غير موجودة على قائمة Lenovo.في جانب ThinkSystem، NE1032 وNE1032T، النظام هو CNOS وليس ENOS، وهناك المدخل هو أمر على مستوى المنصة للسماح بوحدات الإرسال والاستقبال غير المدعومة بدلاً من حيلة محمّل الإقلاع. لم أُجرّب ذلك بنفسي، لذا تحقق من الصياغة على جهازك قبل التخطيط لنافذة عمل حوله. النمط الأساسي لا يتغيّر: البرنامج الثابت يقارن سلسلة مورّد EEPROM بقائمة ويُعطِّل ما لا يتعرّف عليه.
شيء يستحق الإضافة إلى ذلك: التجاوز (override) لا ينجو بالضرورة من ترقية البرنامج الثابت. إن رفعت صورة جديدة وسقطت المنافذ مجدداً، عد إلى الطرفية التسلسلية وتحقق من
printenvقبل أن تبدأ بسحب الوحدات، فقد يكون المتغير ببساطة قد اختفى.ولا تعامل مفاتيح فك القيد الخاصة بالمورّدين على أنها موثوقة بشكل عام. على Catalyst 9200 مع IOS-XE 16.9.x لا تأثير إطلاقاً لأمر
service unsupported-transceiverبسبب CSCvk03296، وما استخدمه الناس بدلاً من ذلك كانno errdisable recovery cause gbic-invalidفي الإعداد العام، الذي منع إعطاب المنافذ (err-disabled) وسمح بتشغيل وحدات FS وCables and Kits. مورّد مختلف، نفس الدرس: المفتاح الموثَّق والمفتاح الذي يعمل فعلاً ليسا دائماً نفس المفتاح.