IBM Flex System EN4093 يُسقط منافذ SFP+ الرابطة (trunk) إلى ERRDISABLE عند الإقلاع وأثناء التشغيل
منظومتان من Flex System، كل منها بمحوّل EN4093R 10Gb Scalable Switch (الخيار 49Y4270) كوحدة شبكة. تعود المنافذ معطّلة بسبب خطأ (error-disabled) بعد حدث انقطاع كهرباء للشاسيه، وبشكل أقل تكراراً تسقط في نفس الحالة أثناء التشغيل. ليست دائماً نفس المنافذ، وهذا ما يجعل تتبع المشكلة مرهقاً.
الإعداد:
- محوّل IBM Flex System EN4093 10Gb Scalable Switch، الخيار 49Y4270
- رابط صاعد (uplink trunk) من أربعة منافذ إلى النواة، بصريات IBM بالإضافة إلى كابل DAC أُضيف لاحقاً
- منفذ QSFP+ مُقسَّم (breakout) نحو المنظومة الثانية
- MSTP يعمل على جانبنا، والنواة من مورّد مختلف
ما تُظهره قائمة المنافذ بعد الإقلاع:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesما جُرّب:
- shutdown / no shutdown على المنافذ المتأثرة يُعيد أغلبها حتى الحدث التالي
- تنظيف وإعادة تركيب كل ألياف الرابط، دون تغيير في النمط
- مقارنة إعدادات المنفذ في الطرف البعيد، السرعات متطابقة نظرياً
ما الذي يدفع هذه المنافذ فعلياً إلى errdisable، وهل هناك طريقة لمنع حدوث ذلك في كل إقلاع بدلاً من تصفيته يدوياً في كل مرة؟
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 5
لدى هذا المحوّل سبع حالات موثّقة تُعطّل المنفذ، ولا علاقة تُذكر بينها:
حالتك هي الرابعة، وهي الأكثر شيوعاً بين الناس، لأنها الحالة التي تصنعها بنفسك: امزج سرعات أو أنواع الوحدات داخل رابط واحد وسيعترض المحوّل. كابل DAC واحد بجانب ثلاث وحدات بصرية كافٍ لذلك. أخرج الـDAC من هناك واملأ الفتحة بوحدة تطابق الثلاث الأخرى.
بالنسبة للمنفذ الذي يقع في كاشف الترنّح، إعادة تدويره لا تزال هي طريقة الاستعادة الموثّقة:
بعد ذلك، راجع إعدادات شجرة الامتداد (spanning tree) على ذلك الرابط وافحص النحاس والألياف يدوياً. اتبع أي تغيير في الإعداد بإعادة تحميل (reload)، وإلا فإن الحالة قيد التشغيل تتوقف بصمت عن مطابقة ما تظن أنك ضبطته.
أمران لا تتوقعهما. اثنتان من هذه الحالات السبع تُبقيان المنفذ معطّلاً بعد انتهاء المهلة وتحتاجان تدخلاً يدوياً على المنفذ. ولا يُصلح أي إصدار من البرنامج الثابت هذا - موقف المورّد هو أن تضبط إعداداتك للالتفاف حوله، لذا وحدات متطابقة عبر كل عضو في الرابط زائد ألياف نظيفة هو أقصى ما يمكن فعله للوقاية.
وجود سببين مختلفين في نفس اللصق هو المكان الذي سأبدأ منه. هل يعود منفذ معين معطّلاً دائماً لنفس السبب، أم أن منفذاً سقط بسبب القدرات في هذا الإقلاع يُشغّل كاشف الترنّح في المرة التالية؟ سبب يبقى ثابتاً لكل منفذ وسبب يتجول هما تحقيقان منفصلان، وواحد منهما فقط ينتهي بك إلى شراء عتاد جديد.
الأمر الثاني الذي يستحق التأكد منه هو ما تُشغّله النواة لشجرة الامتداد. أنتم على MSTP؛ إن كان الطرف البعيد يضع إطارات BPDU بنكهة Cisco/PVST على تلك الروابط الصاعدة، فلدى هذا المحوّل آلية حماية تتفاعل بالضبط مع ذلك وتُسقط المنفذ، ومن الخارج يبدو ذلك تماماً كالعطل الذي تلاحقه بالفعل. هل يمكنك معرفة ما إذا كانت أي من حالات السقوط تتزامن مع تغيير في طوبولوجيا النواة بدلاً من إقلاعاتكم أنتم؟
لكل منفذ الأمر ثابت، لكن عبر الجهاز كله ليس كذلك. أعضاء الرابط الذين يسقطون يعودون دائماً بسبب عدم تطابق قدرات الرابط، والمنفذ الوصول رقم 5 لا يُشغّل سوى كاشف الترنّح، دون أن أجد نمطاً في أي فاصل زمني. فعلاً يبدو الأمر كعطلين يرتديان نفس الغلاف.
شجرة الامتداد على الطرف البعيد لا يمكنني الإجابة عنها بعد - النواة تخص فريقاً آخر وقد سألتهم عمّا يُرسله فعلياً على تلك الروابط الصاعدة. لا شيء في سجلنا يربط سقوطاً بتغيير طوبولوجيا هناك حتى الآن، لكنني كنت أقرأه بحثاً عن أحداث الرابط وليس لهذا الغرض، لذا لن أعتبره مستبعداً.
مورّد مختلف، لكن نفس الشكل. كان لدينا FortiGate 201F متصل بـ FortiSwitch 548D عبر SFP+ بكابل DAC خاص بـFortinet بينهما، ورابط الـ10Gbps ببساطة لم يبقَ مرفوعاً - كان يسقط مهما فعلنا بالسرعة والإرسال الثنائي، والعودة بكلا الطرفين من FortiOS 7.4 إلى 7.2.5 لم يغيّر شيئاً.
ما نجح في النهاية كان كابل DAC أقصر من Fortinet مع تعطيل STP على ذلك الرابط بالذات، وبقي مرفوعاً منذ ذلك الحين. الجزء الذي يستحق النقل هو المنطق الذي جاء بعد ذلك: كلما طال مسار النحاس السلبي (passive)، ازداد تدهور الإشارة عند وصولها، لذا عند 10G أي كابل DAC طويل أو حدّي يستحق أن يكون على قائمة الشك بغض النظر عن الملصق المطبوع عليه. مع ثلاث وحدات بصرية وكابل DAC واحد في رابط errdisable، سأنظر بجدية إلى العنصر الشاذ.
شيء واحد يجب فعله قبل أن تلمس أي عتاد: سجّل الإيقاع الدقيق لحالات الترنّح مقابل طوابع الوقت في السجل.
على محوّل غير ذي صلة إطلاقاً، TL-SG3452X، كل منفذ SFP+ مأهول كان يسقط ويرتفع كل عشر إلى خمس عشرة دقيقة مع رسائل STP في السجل عند كل ترنّح، والاستنتاج الواضح كان بصريات معطوبة - إلى أن تذبذب كابل DAC أصلي من نوع TL-SM5220-1M بنفس الإيقاع تماماً. ذلك قضى على نظرية البصريات في اختبار واحد وأشار بدلاً من ذلك إلى تراجع في البرنامج الثابت؛ الحل الوحيد الذي نجح هناك كان البقاء على البناء الأقدم.
فاصل زمني منتظم يعني أن شيئاً ما ينتهي وقته حسب جدول. فاصل عشوائي يعني شيئاً مادياً. اختبار رخيص، ويوفّر عليك شراء وحدات لا تحتاجها. كما يستحق الأمر الاحتفاظ بصورة البرنامج الثابت السابقة بحيث يبقى التراجع خياراً متاحاً.