نحو 15% فقدان حزم عبر وحدة نحاسية S+RJ10 SFP+ على CRS518-16XS-2XQ بينما المسار المباشر 100G نظيف
ندفع حركة بيانات من خادم مختبري إلى CRS518-16XS-2XQ عبر رابط صاعد QSFP28 بسرعة 100G، وتخرج من المحول عبر وحدة نحاسية MikroTik S+RJ10 SFP+ إلى مضيف RJ45 عادي بسرعة 1G. الجانب المستقبِل يفقد جزءًا كبيرًا من الحزم ولا يمكنني تحديد السبب بوضوح.
الإعداد:
- MikroTik CRS518-16XS-2XQ، رابط صاعد QSFP28 بسرعة 100G من مصدر الحركة
- وحدة نحاسية MikroTik S+RJ10 SFP+ في أحد الأقفاص، جهاز RJ45 بسرعة 1G في الطرف البعيد
- التقاط يعمل على المضيف المستقبِل
ما يقوله الالتقاط:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%ما جُرِّب حتى الآن:
- وصلت نفس المصدر مباشرة عند 100G، لا فقدان إطلاقًا، إذًا المرسل نفسه سليم
- خفّضت حمل معالج المحول، وهو الآن عند 1% بينما لا يزال الفقدان يحدث
- أعدت تركيب S+RJ10 واستبدلت كابل الوصل إلى جهاز 1G
الوحدة النحاسية هي المشتبه به الرئيسي عندي الآن، لكن الرابط نظيف والواجهة لا تُظهر أي أخطاء إطلاقًا. هل S+RJ10 معروفة بابتلاع حركة البيانات هكذا، أم يجب أن أبحث في مكان آخر داخل المحول؟
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
معدل 400-500 ميجابت في الثانية مع مرسل متقطع (bursty) هو القصة كاملة. حركة بياناتك ليست موزعة بالتساوي: انفجارات قصيرة تغادر المصدر أسرع من 1 جيجابت في الثانية، وكل ما هو فوق ذلك الخط يجب أن يبقى في مخزن الخروج (egress buffer) للمنفذ حتى يُفرّغه جانب 1G. عندما يمتلئ المخزن، يُسقط المحول. هذا بالضبط ما تخبرك به حركة rx-overflow، ولهذا السبب لا يُظهر الاتصال المباشر بسرعة 100G شيئًا - لا يوجد خفض سرعة هناك للتخزين ضده.
الوحدة البصرية بريئة. أي شيء في ذلك القفص، نحاسي أو ضوئي، كان سيتصرف بنفس الطريقة، لأن الإسقاط يحدث عند خفض السرعة من 100G إلى 1G وليس داخل الوحدة.
شيئان للقيام بهما. الإصلاح الحقيقي على المرسل: نظّم وتيرته بحيث تُوزَّع الحزم بالتساوي بدلاً من كتابتها على شكل انفجارات. بمجرد أن يتوقف المصدر عن إنتاج انفجارات أعلى من معدل الخروج، يختفي الفقدان.
على المحول يمكنك جعل وضع المخزن أقل عدائية:
هذا يشتري مساحة إضافية ويسمح لانفجار بالاستمرار لفترة أطول، لكنه لا يزيل السبب - إذا كان المرسل ينفجر بقوة كافية ولفترة كافية، لن ينقذك أي حجم مخزن. استمر بمراقبة إحصائيات QoS الخاصة بالمحول وعدادات rx-overflow بعد التغيير، حتى ترى ما إذا كنت لا تزال تصطدم بالسقف أم تلمسه أحيانًا فقط.
الدرس العام يستحق الاحتفاظ به: منفذ برابط نظيف، بلا أخطاء، ووحدة سليمة يمكنه مع ذلك إسقاط نسبة مزدوجة الرقم من حركة البيانات فقط بسبب خفض سرعة بين منفذين.
قبل اتهام الوحدة، انظر إلى ما تقوله عدادات المنفذ فعلاً. شغّل
على منفذ الدخول 100G وعلى القفص الذي يحتوي S+RJ10، واذهب تحديدًا إلى سطر rx-overflow بدلاً من عدادات أخطاء rx/tx المعتادة. وحدة SFP+ نحاسية معطلة فعلاً تُعلن عن نفسها كأخطاء FCS أو رابط متذبذب، وليس كخفض 15% مرتب من تدفق سليم في باقي الأمور.
سؤال ثانٍ: ما هو المعدل المتوسط عبر ذلك المسار، وهل لديك فكرة عن الذروات؟ فقدان حزمة من كل سبع مع معالج عند 1% يبدو أقرب بكثير إلى نفاد مخزن منفذ الخروج منه إلى عطل في وحدة الإرسال والاستقبال.
العدادات أولاً: لا أخطاء على أي منفذ، الرابط يبقى نشطًا طوال الوقت والوحدة لا تبلغ عن أي شيء غير عادي. rx-overflow هو المكان الوحيد الذي تتحرك فيه الأرقام إطلاقًا.
بخصوص المعدل، يبلغ متوسط المسار 400-500 ميجابت في الثانية، إذًا على الورق هو بعيد تمامًا عن إشباع جانب 1G. لا أملك قياسًا للذروة، لكن حركة البيانات متقطعة بطبيعتها - يكتب المرسل دفعة ثم يصمت لفترة. المعالج لا يزال عند 1% بينما تختفي الحزم.
عطل مختلف، نفس الدرس بخصوص الثقة بالعدادات بدلاً من الحدس. كان لدي CRS354-48G-4S+2Q+RM على SwOS 2.18 مع نمو مستمر في Rx FCS Errors على كلا منفذي QSFP+، وRx MAC Errors بمعدل أقل. كان كلا المنفذين عند 40G full duplex بـ MTU 1500، وعلى الطرف البعيد كانت مضيفات ESXi ببطاقات Mellanox ConnectX-3 Pro CX324A.
الجزء المثير: جانب بطاقة الشبكة لم يبلغ عن شيء إطلاقًا.
نظيف. الكابلات المعروفة بسلامتها لم تغيّر شيئًا، ومنافذ SFP+ بسرعة 10G في نفس الصندوق بقيت خالية من الأخطاء طوال الوقت. لم أحصل أبدًا على تشخيص حقيقي - نقل المحول من SwOS إلى RouterOS جعل العدادات تختفي، وهو ما أعتبره إخفاءً للمشكلة وليس حلاً لها.
الطريقة التي صمدت: امسح العدادات، أعد قراءتها على فترة ثابتة وانظر ما إذا كانت الأخطاء تتبع حجم حركة البيانات. في حالتك ستتبع الانفجارات، وفي حالتي لم تتبع شيئًا مفيدًا، وذلك الفرق وحده يخبرك أي جانب تستمر بالحفر فيه.
شيء يجب تذكّره أثناء تجربتك على ذلك المنفذ: لا تلجأ إلى إجبار السرعة والازدواجية كمخرج. السلوك الموثّق لوحدات MikroTik النحاسية، S-RJ01 وS+RJ10 على حد سواء، هو أنها تعمل فقط مع تفعيل التفاوض التلقائي - ثبّت المعدل يدويًا ولن يعمل الرابط إطلاقًا. الممارسة تناقض هذا جزئيًا، إذ يبلغ بعض مالكي RB5009 وRB4011 عن العكس ولم يحصلوا على استقرار S-RJ01 إلا بإجبار 1G full duplex، لذا هي مسألة "جرّب كليهما على عتادك الخاص" وليست قاعدة. على أي حال هذا التفاف عن مشكلتك الفعلية، وهي في جانب المخزن.
تفصيل آخر عن S+RJ10 يستحق المعرفة لاحقًا: تستهلك طاقة أكثر بشكل ملحوظ من وحدة بصرية عادية وتسخن، لذا لا يُنصح بها في جهاز مبرَّد سلبيًا دون تهوية إضافية. إذا بدأت تلك الوحدة بسوء التصرف في شاسيه دافئ، فدرجة الحرارة هي أول ما سأتحقق منه.