CodingBox Q&A Ask question

وصلة CE6800 من Huawei العلوية بسرعة 100GE إلى جهاز Profitap XX-3200G لا تعمل أبداً مع موديولات SR4 البصرية

Asked Active Viewed 45 AI translation from English
4

نستبدل زوج التجميع (aggregation) الحالي لدى عميل بمعدات CloudEngine، والوصلة الوحيدة التي ترفض العمل هي تغذية 100GE إلى موزّع الحزم (packet broker) الخاص بهم. كل شيء آخر على المفتاح تم تركيبه دون أي مشاكل.

  • Huawei CloudEngine 6800، منفذ 100GE
  • موديولات QSFP28 من نوع 100GBASE-SR4، قطع Huawei، واحد في كل طرف
  • موزّع حزم Profitap XX-3200G في الطرف البعيد

يرى كلا الطرفين موديوله. لا يحتوي سجل المفتاح إلا على مدخلات تركيب وإزالة الموديولات من وقت إعادة تركيبي للأشياء، بدون أي إنذارات إطلاقاً، والواجهة تبقى down فقط:

<CE6800> display interface 100GE1/0/1
 ...
 FEC : RS-FEC

ما جُرِّب حتى الآن:

  • استبدلت كلا الموديولين بموديولات احتياطية ونظّفت أطراف MPO، دون تغيير؛
  • نقلت الوصلة إلى منفذ 100GE مختلف على المفتاح؛
  • تحققت من جانب موزّع الحزم، فهو يكتشف موديوله ولا يُبلغ عن أي خطأ.

إذن الموديولات البصرية معترف بها في كلا الطرفين، ولا شيء يشتكي، ولا توجد وصلة. ما الشيء الآخر الذي يجب أن يتطابق بين منفذ 100GE من CloudEngine وجهاز من طرف ثالث قبل أن تتدرب (train) الوصلة؟

Comments 3

Accepted answer

هذا عدم تطابق في FEC. يفعّل CloudEngine ميزة RS-FEC افتراضياً على منافذ 100GE بموديولات SR4، وليس لدى موزّع الحزم أي إعداد لـ FEC ولذلك يعمل بدونها، والطرفان اللذان يختلفان في FEC لا ينهيان أبداً عملية التدريب (training). لا شيء معطوب، لذا لا يُسجَّل شيء، وهذا سبب احتواء السجل فقط على رسائل التركيب والإزالة الخاصة بك.

أوقفها على المفتاح، في عرض الواجهة:

fec mode none
commit

يفعل undo fec mode نفس الشيء. السطر الثاني هو المهم. تهيئة CE تتم على مرحلتين، وأمر fec mode none غير الملتزم به (uncommitted) يبدو صحيحاً تماماً عند قراءة التهيئة مرة أخرى بينما يبقى المنفذ down تماماً كما كان. شاهدت حالة عميل تستمر يوماً إضافياً لهذا السبب، مع اقتناع الجميع بأن FEC قد عُطِّلت بالفعل.

بعد الالتزام (commit)، ينبغي أن يُظهر أمر display interface القيمة FEC: NONE وأن يبدأ المنفذ بالتدريب.

إذا اكتسب الطرف البعيد يوماً إعداداً لـ FEC، فالحل الأفضل هو تفعيل RS-FEC هناك وترك المفتاح على إعداده الافتراضي، لأنك في الواقع تريد التصحيح على 100G. بين مورّدين مختلفين، سأضبط FEC صراحةً في كلا الجانبين بدلاً من الوثوق بأي تفاوض تلقائي عليه.

3 United Statesphotonrunner70US Show original (English) AI translation

ماذا يقول موزّع الحزم عن FEC في جانبه، إذا كان يقول أي شيء أصلاً؟ لقد نشرت بالفعل النصف المثير للاهتمام بنفسك: منفذ المفتاح يعمل بـ RS-FEC. Huawei واضحة في أن كلا طرفي وصلة 100GE يجب أن يستخدما نفس وضع FEC، وإلا لن تعمل الواجهتان أبداً، وهذا الفشل يبدو تماماً مثل حالتك: موديولان سليمان، لا إنذار، لا سجل، منفذ down.

معظم موزّعات الحزم وأجهزة الاستنساخ (taps) التي عملت معها لا تعرض أي إعداد لـ FEC إطلاقاً، مما يعني أنها تعمل بدونها والمفتاح هو الجانب الذي يجب أن يتنازل. تأكد من ذلك أولاً، ثم غيّر شيئاً واحداً.

3 Netherlandsopticguru22NL Show original (English) AI translation

يستحق الإضافة أن الافتراضي في CloudEngine ليس قيمة واحدة، بل يعتمد على الموديول. QSFP28-100G-LR4 وQSFP28-100G-LR1 يعملان بـ FEC مطفأة وفقاً لمعيار IEEE 802.3، بينما جميع أنواع QSFP28 الأخرى تكون افتراضياً بـ FEC مفعّلة. لذا فإن نصيحة إيقافها ببساطة خاطئة على وصلة LR4، حيث يكون المفتاح مطفأً بالفعل وعدم التطابق يعيش في الطرف الآخر.

قاعدتان أخريان من نفس الفصل وقعت فيهما:

  • تريد QSFP28-100G-BIDI وQSFP28-100G-DR وQSFP-100G-FR1 تعطيل RS-FEC على المنفذ قبل تركيب الموديول. فهي تنفّذ FEC الخاصة بها في معالج الإشارة الرقمي (DSP) للموديول، ومع بقاء RS-FEC مفعّلة على المضيف تحصل على Down (Transceiver type mismatch) بدلاً من منفذ down عادي.
  • على 25GE يسير الأمر بالاتجاه المعاكس. على أجهزة CE6863 وCE6863E وCE6863K وCE6881E، يحتاج كابل SFP28 عالي السرعة بأي طول غير متر واحد إلى تفعيل RS-FEC، وإلا يبقى المنفذ في حالة Down (Transceiver type mismatch).

لذا تحقق مما تحمله فعلياً بأمر display transceiver interface 100GE1/0/1 verbose قبل أن تقرر في أي اتجاه تضبط FEC، وتذكر الالتزام (commit) في كلتا الحالتين.

0 GermanycoreadminDE Show original (English) AI translation
Log in to comment. Log in