TL-SG3428X-M2 (V1): جاعة SFP+ رقم 26 لا تعطي أي رابط مع أي TL-SM5310-T، والجاعة 27 تنقطع للحظة معها
أدير شبكة مكتب صغير، خزانة سويتشات واحدة، وأربع جاعات SFP+ على سويتش الوصول لدينا تحمل روابط 10G إلى رف السيرفرات. عملت لأشهر دون أي مشكلة والآن اختفت جاعة واحدة ببساطة.
- TP-Link TL-SG3428X-M2 (V1)، فيرموير 1.20.4 Build 20241104 Rel.40746، مُدار عبر Omada
- أربع وحدات TP-Link TL-SM5310-T نحاسية 10GBASE-T في منافذ SFP+ من 25 إلى 28
- كابلات CAT6A، والأطراف البعيدة هي سيرفران وجهاز NAS
حالات المنافذ كما هي الآن:
port 25 up, 10G
port 26 down, no link LED with any module
port 27 up, 10G, but drops for a moment whenever a cable goes into or out of port 26
port 28 up, 10Gما جربته:
- ناوبت الوحدات بين الجاعات الأربع كلها: الوحدة من المنفذ 26 تعمل بشكل جيد في 25 و28، وكل وحدة أضعها في 26 تبقى مطفأة، إذن الوحدات نفسها سليمة
- كابلات جديدة، منافذ بعيدة مختلفة، لا تغيير
- إعادة تشغيل السويتش، تعطيل/تفعيل المنفذ، لا تغيير
الجزء الذي لا أستطيع تفسيره هو ارتعاش المنفذ 27 بينما الشيء الوحيد الذي ألمسه هو المنفذ 26. هل الجاعة 26 معطوبة وتستحق طلب استبدال (RMA)، أم أن هناك شيئاً آخر يجب استبعاده أولاً؟
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 6
هذا تراجع (regression) في الفيرموير 1.20.4 Build 20241104، وليس عطلاً في العتاد. النمط الذي تصفه - جاعة SFP+ واحدة لا تضيء أبداً مع وحدات معروفة السلامة، بالإضافة إلى جاعة مجاورة ترتعش عندما تلمس الميتة - هو بالضبط ما يفعله ذلك الإصدار مع وحدات TL-SM5310-T النحاسية.
أعد السويتش إلى الإصدار السابق وتعود المنافذ. عملياً:
أقر موظفو TP-Link أنفسهم بوجود خلل في ذلك الإصدار على سويتشات Omada المهيأة للمتحكم v5.14، وقالوا إن الأمر قيد الدراسة، ونصحوا بالبقاء على الفيرموير الأقدم في الوقت الحالي. لذا لا تستهلك حالة دعم على العتاد، استهلكها على رقم الإصدار.
إذا لم تستطع فعلاً التراجع، فالحل المؤقت الوحيد هو العيش بالجاعات الثلاث التي لا تزال تعمل وترك المنفذ 26 فارغاً. هذا ليس إصلاحاً، بل مجرد طريقة للبقاء في الخدمة حتى يظهر إصدار مصحَّح.
قبل أن تملأ نموذج طلب استبدال (RMA): متى بدأ هذا، وهل استلم السويتش تحديث فيرموير في نفس الوقت تقريباً؟ 1.20.4 Build 20241104 حديث نسبياً، والمتحكم سيدفع بكل سرور صورة جديدة من تلقاء نفسه إذا تُركت التحديثات التلقائية مفعّلة.
من الجدير أيضاً تحديده: هل يرتعش المنفذ 27 فقط عندما توجد وحدة في المنفذ 26، أم أيضاً عندما يكون 26 فارغاً؟ الجاعة الميتة عادة لا تجعل جاراً يرتعش. هذا الجزء يوحي بشدة بالبرمجيات خلف المنافذ أكثر من وصلة لحام متصدعة.
نفس السويتش، نفس الإصدار هنا، فأنت لست وحدك. المنفذ 25 كان بخير، المنفذ 26 لم يعط أي مصباح رابط مع كل وحدة أملكها، و27 و28 كانا يظهران ويختفيان - أحدهما يغذي EAP783، لذا كان كل انقطاع واضحاً جداً. مررت بنفس طقوس تبديل الوحدات وأقنعت نفسي بأن الجاعة ميتة.
لم تكن الجاعة. الجهاز كان قد استلم تحديث فيرموير قبل بدء المشكلة بقليل، والعودة إلى الصورة السابقة أعادت جميع منافذ SFP+ الأربعة. تحقق من سجل التحديثات قبل أن تشحن أي شيء إلى أي مكان.
مؤكَّد، ومن المحرج كم كنت قريباً من إرسال السويتش بعيداً. سجل التحديثات يُظهر وصول 1.20.4 Build 20241104 قبل أيام قليلة من تصرف المنافذ بغرابة، ولم أبدأه يدوياً أبداً، إذن جاء من تلقاء نفسه.
تراجعت إلى الإصدار السابق، أعدت الاعتماد، وجميع الجاعات الأربع تعمل الآن بسرعة 10G بما فيها المنفذ 26. المنفذ 27 لم يعد يرتعش عندما أعمل على 26. التحديثات التلقائية معطّلة الآن والصورة القديمة موجودة على خادم الملفات بجانب نسخة الإعدادات الاحتياطية.
للأرشيف: نفس العائلة لديها فخ فيرموير آخر يستحق المعرفة. على TL-SX3008F (V1) مع SM5310-T(UN) يغذي محطة عمل، ترك الفيرموير 1.20.2 و1.20.3 منفذ SFP+ ميتاً بمجرد أن ينام الحاسوب أو يُطفأ. نقل الوحدة إلى جاعة فارغة كان يعمل مرة واحدة بالضبط لكل جاعة، وبعد استخدام كل الجاعات كانت إعادة تشغيل السويتش وحدها تعيد المنافذ. تثبيت المنفذ على 1G تجنّب المشكلة، على حساب السرعة التي دفعت ثمنها.
مالك آخر واجه نفس الشيء مع وحدات RJ45 من 10Gtek (ASF-10G2-T)، وWiitek وXicom خلف محول Iocrest AQC113. التراجع إلى 1.20.0 Build 20231011 Rel.42220 حل المشكلة لكلينا. عرض مختلف، نفس الدرس: معالجة SFP+ النحاسية في هذه الإصدارات هي حيث تعيش العلل.
احتفظ بشيء آخر في ذهنك مع هذا الخط من السويتشات: الوحدة الخاملة قد تكلفك أكثر من منفذ. على TL-SX3016F يعمل بـ 1.0.0 Build 20210730 Rel.65115، جلس المعالج عند 87-89% دون أي حركة بيانات على الإطلاق ووضع سطر CPU RISING THRESHOLD في السجل كل ثلاث دقائق.
الحمل كان يتتبع عدد الوحدات المركبة - وحدة واحدة 0-1%، اثنتان 73-76%، ثلاث أو أكثر 88-90% - وتبيّن أن السبب وحدات Mellanox MFM1T02A-SR بفيبر موصول لكن لا شيء مضاء في الطرف البعيد، فبقي الرابط معطلاً. استبدال تلك بـ Ubiquiti UF-MM-10G أبقى المعالج منخفضاً مهما كان يفعل المنفذ، وسحب الوحدات غير المستخدمة ببساطة عالج الأمر أيضاً. إجابة TP-Link نفسها كانت أن وحدة موجودة برابط معطل مكلفة ببساطة لدارة الرقاقة، وأن الحمل ينخفض بمجرد أن يرتبط المنفذ بشكل صحيح. هذا يترك النصف المحرج بلا تفسير: غيّر العلامة التجارية، اترك الوحدة خاملة تماماً كما هي، ويبقى المعالج هادئاً. لذا بمجرد عودتك إلى الفيرموير الأقدم، ألقِ نظرة على رسم المعالج البياني أيضاً.