منفذ SFP+ في Turris Omnia NG: أي وحدات نحاسية RJ-45 من جهات خارجية تعمل فعلًا

Asked 18 days ago Active 17 days ago Viewed 133 AI translation from English

أشغّل جهاز Turris Omnia NG في المنزل، وآخر ما يتبقى على منفذ WAN المعدني هو وصلة بطول مترين إلى جهاز موجّه مزوّد الخدمة (ISP). أرغب في نقل هذه الوصلة إلى منفذ SFP+ وتحرير المنفذ النحاسي لجانب المختبر. الوحدة النحاسية الرسمية من Turris لمنفذ SFP+ (RTROM01-RTSF-10G) يبلغ سعرها تقريبًا سعر محول صغير، ومن الصعب جدًا الحصول عليها أصلًا.

الإعداد:

Turris Omnia NG، بالبرنامج الثابت الأصلي، منفذ SFP+ فارغ حاليًا
وصلة RJ-45 قصيرة إلى موجّه مزوّد الخدمة، بسرعة 1G في ذلك الجانب
مضيفان بسرعة 10G في جانب المختبر أرغب في الوصول إليهما بسرعة أعلى من 1G في النهاية
لا توجد وحدات SFP+ نحاسية احتياطية في الدرج للاختبار بها

كل ما لديّ للحكم على الوحدة عند وصولها:

dmesg | grep -i sfp
ethtool -m eth2

ما فعلته حتى الآن: بحثت عن قائمة توافق رسمية لهذا المنفذ ولم أجد شيئًا، وسألت أحد البائعين عمّا إذا كان يقبل استرجاع الوحدة إذا لم تعمل.

إذن السؤال بسيط - ما هي وحدات RJ-45 النحاسية بسرعة 10G أو 2.5G التي يستخدمها الناس فعلًا في منفذ NG، وما هي الوحدات المعروف أنها لا تعمل؟ أفضّل شراء شيء يعمل في مكان ما على المخاطرة ثلاث مرات.

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 简体中文

netops KZ

Comments 4

Accepted answer

لا توجد قائمة توافق من المورّد لهذا المنفذ ولن توجد - فعدد التوليفات بين الوحدات والبرامج الثابتة يجعل صيانتها غير عملية، لذا فإن ما تحصل عليه بدلًا من ذلك هو تقارير المستخدمين. من واقع ما يشغّله الناس في NG: وحدة 10Gtek RJ-45 SFP+ من نوع 1.25/2.5/5/10GBASE-T هي الأكثر نجاحًا، ووحدة ipolex 10GBASE-T تعمل، ووحدة MikroTik S+RJ10 تعمل، وتم الإبلاغ أيضًا أن وحدة Xicom 2.5G النحاسية الرخيصة تعمل بشكل جيد. وإذا كانت المسافة قصيرة بما يكفي، فإن كابلات DAC من 10Gtek أيضًا ضمن الخيارات التي تعمل. وفي الجانب الآخر، أُبلغ أن وحدة Solarflare SFM10G-TX لا تعمل.

نقطتان عمليتان. اشترِ من بائع يقبل الإرجاع - الدعم الخاص بهذا الجهاز محدود هنا، وقد ينتهي بك الأمر بتبديل الماركات بدلًا من التشخيص. وتوقّع أن تعمل وحدة 10GBASE-T داخل هيكل SFP+ بحرارة عالية، وهو أمر مهم إذا كان الموجّه موضوعًا داخل خزانة مغلقة.

عند وصولها، تحقق من dmesg | grep -i sfp مباشرة بعد التركيب واقرأ ethtool -m eth2. فإذا لم تتعرّف النواة (kernel) على الوحدة هناك، فلن تُنقذها أي كمية من إعدادات الواجهة.

netadmin16EG 17 days ago Show original (English) AI translation

يستحق الإضافة لأي شخص يصل إلى هنا وهو يملك Omnia الكلاسيكي وليس NG. في ذلك الجهاز، المنفذ لا يمنحك أي واجهة إضافية إطلاقًا. المنفذ ومقبس WAN المعدني كلاهما خلف عنوان MAC واحد، eth2، ولا يكون موصولًا به فعليًا في أي لحظة سوى أحدهما - وأيهما يعتمد على ملف device tree blob الذي يحمّله الموجّه عند الإقلاع. لذا فإن وحدة نحاسية سليمة تمامًا تبدو ميتة تمامًا: لا يظهر أي جديد في قائمة الواجهات، بل إن WAN المعدني يفقد عنوانه طوال بقاء الوحدة مُركّبة. وجّه /boot/dtb نحو النسخة الخاصة بـ SFP، وأعد التشغيل، وتتغير الصورة:

cd /boot/
rm dtb
ln -s armada-385-turris-omnia-sfp.dtb dtb
reboot

فعلت بالضبط هذا على TurrisOS 6.2.3 مع وحدة نحاسية FS من نوع 2.5GBASE-T، وارتفع WAN إلى 2.5Gbps فور إعادة التشغيل. لا أعرف إن كان NG يحتاج إلى شيء مشابه، لكن تحقق من الجهاز قبل أن تحكم على وحدة بأنها معطوبة.

rackhubKZ 17 days ago Show original (English) AI translation

شكرًا، هذه هي القائمة التي كنت أبحث عنها. سأطلب وحدة 10Gtek، ومن مكان يقبل استرجاعها.

شيء كان عليّ ذكره في السؤال، بما أن الوحدة الرسمية تظهر في كل نقاش من هذا النوع: كانت لديّ وحدة RTROM01-RTSF-10G في هذا المنفذ سابقًا. عملت لفترة، ثم بعد نحو شهر بدأت بإطلاق أخطاء اتصال، فاستسلمت ونقلت الرابط إلى منفذ إيثرنت عادي. إذن فالخيار الأغلى ليس بالضرورة الأكثر أمانًا هنا - وهذا بالضبط سبب طلبي وحدات يستخدمها الناس فعليًا وليس توصية.

netopsKZ 17 days ago Show original (English) AI translation

زاوية مختلفة من نفس المشكلة، ونفس الخلاصة. على Omnia الكلاسيكي، الوحدة الوحيدة التي أستطيع الشهادة لها هي TP-Link TL-SM321B - أحادية الاتجاهين (bidirectional) بمعيار 1000Base-BX، بطول موجي 1310 نانومتر، موصل LC. تلتقطها النواة (kernel) دون أي تدخل، وأحصل على نحو 920 ميغابت/ثانية من الحمولة الفعلية عبرها. ولا حاجة للبحث عن الـ 80 ميغابت/ثانية المفقودة أيضًا: الخط نفسه يعمل بسرعة 1.25 غيغابت/ثانية، وبين ترميز 8b10b وتأطير Ethernet، هذا بالضبط ما يستقر عنده المعدل القابل للاستخدام.

مثال معاكس من نفس الموجّه: وحدة CTS SFP-31W2ASM10-DR عملت بشكل جيد تحت Turris OS 3.x وتوقفت تمامًا بعد انتقال الجهاز إلى 4.0 - والسبب هناك كان نموذج إعادة تصميم VLAN وإعدادات المحول، وليس الوحدة نفسها. وتذكّر من أين تأتي الإصلاحات: عمل SFP يدخل إلى فرع OpenWrt الرئيسي (master) قبل وقت طويل من ظهوره في فرع Turris المستقر، لذا فإن شيئًا يرفض العمل اليوم قد يعمل بهدوء بعد إصدارين أو ثلاثة.

opticguru22NL 17 days ago Show original (English) AI translation