Catalyst 3850 يُعطّل المنفذ (err-disable) عندما يستخدم ThinkSystem SR650 بصريات Lenovo 46C3447 من نوع SR
خادم ESXi جديد يدخل رفاً متصلاً بمحوّل 3850 في الحرم الجامعي. الإدارة عبر النحاس ارتفعت دون مشاكل، لكن روابط uplink بسرعة 10G لم ترتفع: بمجرد إقلاع الخادم، يسقط منفذ المحوّل في حالة err-disable ولا يرى المضيف شيئاً على vmnic ذلك.
- Lenovo ThinkSystem SR650، 7X06CTO1WW، مع بطاقة Emulex VFA5.2 2x10GbE SFP+
- وحدات Lenovo 10GBASE-SR، 46C3447، في البطاقة
- Cisco WS-C3850-24XS-S مع Cisco SFP-10G-SR في جانب المحوّل
- وصلة OM3 LC-LC بينهما
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableما جُرّب حتى الآن:
- نقل الخادم إلى منفذ آخر على نفس المحوّل، نفس السلوك
- استبدال 46C3447 بتوأمها من منفذ البطاقة الآخر
- كابل تصحيح جديد، وتنظيف وإعادة تركيب الطرفين
الألياف وبصريات جانب المحوّل سليمة بوضوح، إذن هناك شيء يعترض على وحدة Lenovo. أي جانب يعترض هنا، الخادم أم المحوّل، وهل هناك طريقة لجعل 3850 يتعايش معها؟
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
هذا السجل يحسم الأمر.
gbic-invalidهو المحوّل يرفض ما يقرأه كوحدة غير مصرّح بها، والفحص الذي يُطلق يعيش في جانب Cisco، لا في SR650 ولا في ESXi. يعترض على بصريات SR المُشفّرة من Lenovo في ذلك الرابط ويقتل المنفذ قبل أن يُقيَّم الرابط أصلاً، وهذا أيضاً سبب عدم تغيّر شيء عندما نقلت المنافذ واستبدلت الكابلات.سطران في الإعداد العام:
السطر الأول يخبر المحوّل بالاستمرار مع وحدة لا يتعرّف عليها، والثاني يمنع err-disable من إسقاط المنفذ عندما يفشل فحص CRC ذاك. لا شيء منهما بأثر رجعي، لذا أعد تدوير المنفذ بعد ذلك وأعد تركيب الألياف وهو معطّل:
احفظ الإعداد بمجرد أن يرتفع. إن بقي فقط في الإعداد قيد التشغيل، سيعود المنفذ err-disabled بعد إعادة التحميل التالية وستُضطر لتصحيح هذا مجدداً في لحظة أسوأ بكثير.
تنبيهان. أنت الآن خارج إعداد Cisco المدعوم: يعتبرون البصريات من طرف ثالث غير مُختبرة ويمكن لـTAC رفض حالة تشغيل بيني (interoperability) تتضمن واحدة منها، وهذا مهم إن كان هذا الرابط يقع تحت عقد. و
service unsupported-transceiverليس حلاً شاملاً. رسالة crc السيئة نفسها تنجو منه عندما يكون المنفذ نفسه هو العائق، مثلاً فتحة SFP بسرعة 1G فقط دُفعت فيها وحدة 10G، لذا إن بقي المنفذ معطّلاً بعد إعادة التدوير، تحقق من السرعة التي يعمل بها كل طرف فعلياً قبل أن تلوم البصريات مجدداً.قبل أن يخمّن أحد: ماذا يسجّل المحوّل فعلياً عندما يسقط المنفذ؟ err-disable يذكر دائماً سببه، والسبب يغيّر الإجابة تماماً. شكوى أمنية أو CRC بخصوص وحدة مشكلة مختلفة عن ترنّح أو عثرة بروتوكول، والعلاج لواحدة لا يفعل شيئاً للأخرى.
اسحب
show loggingمن حوالي لحظة إقلاع الخادم وانشر الأسطر الخاصة بذلك المنفذ. أكّد أيضاً ما الموجود فعلياً في Te1/0/7، تقول Cisco SFP-10G-SR، فهل 46C3447 هي القطعة الوحيدة غير التابعة لـCisco في ذلك المسار؟السجل من لحظة السقوط، سطران لذلك المنفذ:
إذن الفحص الأمني هو الذي يُطلق، وليس ترنّحاً. ونعم، طرف المحوّل هو Cisco SFP-10G-SR أصلي من صندوق Cisco، ووحدة 46C3447 في الخادم هي القطعة الوحيدة المُشفّرة لـLenovo في المسار. وهذا ما أربكني، لأن الرسالة تذكر المنفذ على المحوّل بدلاً من أي شيء في جانب الخادم.