Supermicro E300-9A على pfSense Plus 22.05: ix2 وix3 يبقيان بحالة no carrier مع كابل DAC يعمل بشكل طبيعي على USW-Aggregation
جدار الحماية لديّ هو Supermicro E300-9A يعمل بـpfSense Plus 22.05، ويرفض كلا منفذي 10G SFP+ العمل. لا ix2 ولا ix3 يُظهران carrier إطلاقًا، مهما وضعت في المقبس.
العتاد:
- Supermicro E300-9A، pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M وكابل twinax سلبي من 10Gtek
- وحدات ألياف Supermicro AXS85-192-M3 كبديل
- Ubiquiti USW-Aggregation على جانب المحول
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 يبدو مماثلًا.
ما جُرّب حتى الآن:
- كلا الكابلين يعملان على USW-Aggregation بين أجهزة أخرى، إذن هما ليسا معطوبين
- استبدلت النحاس بوحدات ألياف AXS85-192-M3، ونفس حالة no carrier على كلا المنفذين
- أعدت تشغيل الجهاز عدة مرات، بما في ذلك إدخال وحدة أثناء تشغيله
هل هناك شيء في هذا الجهاز يجب "ركله" قبل أن تبدأ المقابس بالعمل، أم أنني أنظر إلى منفذين ميتين؟
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 4
إعادة التشغيل الدافئة (warm reboot) لن توصلك إلى شيء - هذه المنافذ تُثبّت حالة الوسيط ولا تعيد فحصها أبدًا عند إعادة التشغيل. أطفئ الجهاز بشكل صحيح، انزع مهايئ الطاقة لدقيقتين، ثم شغّله مجددًا والوحدة مُركّبة بالفعل. هذا ما أعاد كلا المنفذين هنا، ووصف شخص آخر سلوكًا مطابقًا على منفذ Intel X552، وهذا سبب اعتقادي أنها حالة وسيط قديمة (stale) وليست مشكلة في pfSense.
إذا أدخلت وحدة والنظام يعمل بالفعل، أعد تشغيل الواجهة بدلًا من إعادة تشغيل الجهاز:
هذا يجعل التعريف (driver) يفحص المقبس مجددًا. ليس إصلاحًا دائمًا لأي شيء، لكنه يوفر إعادة تشغيل عند تبديل الوحدات على منضدة العمل. تحقق من النتيجة بـ
ifconfig -aبدلًا من اللوحة الأمامية.نفّذ نزع الطاقة الكامل أولًا وتأكد من كلا المقبسين بكابل DAC قبل أن تلمس جانب المحول. تصحيح الأخطاء خطوة بخطوة مهم هنا، لأن "no carrier مع كل وحدة" و"الرابط يعمل بسرعة خاطئة" عادة ما تكونان عطلين منفصلين يصادف وجودهما في نفس مسار الكابل.
نزع الطاقة الكامل نجح. أطفأت الجهاز، نزعت المهايئ، انتظرت دقيقتين، أعدت التشغيل - وعمل كلا المنفذين. عملت حلقة بكابل DAC بين ix2 وix3 وحصلت على رابط 10G نظيف، وزوج AXS85-192-M3 يعمل أيضًا بسرعة 10G بين المنفذين، إذن المقابس والوحدات سليمة.
جانب المحول قصة أخرى. باتجاه USW-Aggregation يتفاوض الرابط دائمًا على 1G فقط، وإذا فرضت 10G على أي من الطرفين ينقطع ويبقى منقطعًا. إذن نصف المشكلة اختفى والنصف المزعج ما زال هنا.
نصف مشكلة التراجع إلى 1G يبدو مألوفًا جدًا. لاحقت نفس العرض على TL-SG3428X وTL-SX3008F: أعد تشغيل خادم متصل بأحد منافذ SFP+ تلك وعاد متفاوضًا على 1G بغض النظر عمّا كان منفذ المحول مهيأً له. Intel X520-DA2، ومهايئات Mellanox وHP، ووحدات Intel E10GSFPSR وبصريات 10GTek، وتحديثات البرنامج الثابت، وعدة إصدارات تعريف على Linux وWindows، وملفات تعريف المنفذ (port profiles) - لا شيء من هذا غيّر أي شيء. إعادة تشغيل المحول، أو تبديل سرعة المنفذ بعيدًا عن 10G ثم إعادتها، كان يستعيد رابط 10G حتى إعادة تشغيل المضيف التالية.
ما أصلح الأمر فعليًا كان تغيير البصريات وليس أي شيء على المضيف: وحدات TP-Link SM5110-SR على طرف المحول وعاد الرابط بسرعة 10G في كل مرة. أكد شخص آخر نفس الشيء على SG3428XMPP. القراءة كانت أن المحول يسيء التفاوض مع بعض الوحدات من طرف ثالث بعد إعادة تعيين رابط من جانب المضيف.
مورّد مختلف في حالتك، لكن الشكل مطابق. قبل أن تشتري مجموعة من أي شيء، استعر وحدة واحدة بعلامة Ubiquiti واختبر منفذًا واحدًا على محول التجميع (aggregation switch).
بخصوص فرض 10G: فعل ذلك على طرف واحد فقط يزيد الأمر سوءًا وليس تحسينًا. الطرف الآخر ما زال يحاول التفاوض وإعداد ثابت لا يعطيه شيئًا للتفاوض معه، لذا يبقى الرابط منقطعًا ببساطة - وهذا بالضبط السلوك الذي تصفه. اضبط السرعة والازدواجية على كلا الطرفين، أو على لا أحد منهما.
حالتان مرتبطتان من عالم MikroTik، في حال ذكّرتاك بشيء. على RB4011 اكتُشفت وحدة Finisar FTLF8524P2BNV-BR مع sfp-rx-loss وsfp-tx-fault كلاهما يظهران no، ومع ذلك قالت الواجهة no-link، لأن SFP بسرعة 1G في مقبس SFP+ يجب تثبيته بدلًا من التفاوض عليه:
ومرة أخرى، على كلا الطرفين. الحالة الثانية كانت CCR1072 حيث بقي التفاوض التلقائي بحالة DONE بعد فقدان رابط ولم يعد التعريف تشغيله أبدًا؛ تعطيل التفاوض التلقائي وتثبيت السرعة أعاد الرابط، على حساب اكتشاف انقطاع الرابط بشكل صحيح.