وصلة CE6800 من Huawei العلوية بسرعة 100GE إلى جهاز Profitap XX-3200G لا تعمل أبداً مع موديولات SR4 البصرية
نستبدل زوج التجميع (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
هذا عدم تطابق في FEC. يفعّل CloudEngine ميزة RS-FEC افتراضياً على منافذ 100GE بموديولات SR4، وليس لدى موزّع الحزم أي إعداد لـ FEC ولذلك يعمل بدونها، والطرفان اللذان يختلفان في FEC لا ينهيان أبداً عملية التدريب (training). لا شيء معطوب، لذا لا يُسجَّل شيء، وهذا سبب احتواء السجل فقط على رسائل التركيب والإزالة الخاصة بك.
أوقفها على المفتاح، في عرض الواجهة:
يفعل
undo fec modeنفس الشيء. السطر الثاني هو المهم. تهيئة CE تتم على مرحلتين، وأمرfec mode noneغير الملتزم به (uncommitted) يبدو صحيحاً تماماً عند قراءة التهيئة مرة أخرى بينما يبقى المنفذ down تماماً كما كان. شاهدت حالة عميل تستمر يوماً إضافياً لهذا السبب، مع اقتناع الجميع بأن FEC قد عُطِّلت بالفعل.بعد الالتزام (commit)، ينبغي أن يُظهر أمر
display interfaceالقيمة FEC: NONE وأن يبدأ المنفذ بالتدريب.إذا اكتسب الطرف البعيد يوماً إعداداً لـ FEC، فالحل الأفضل هو تفعيل RS-FEC هناك وترك المفتاح على إعداده الافتراضي، لأنك في الواقع تريد التصحيح على 100G. بين مورّدين مختلفين، سأضبط FEC صراحةً في كلا الجانبين بدلاً من الوثوق بأي تفاوض تلقائي عليه.
ماذا يقول موزّع الحزم عن FEC في جانبه، إذا كان يقول أي شيء أصلاً؟ لقد نشرت بالفعل النصف المثير للاهتمام بنفسك: منفذ المفتاح يعمل بـ RS-FEC. Huawei واضحة في أن كلا طرفي وصلة 100GE يجب أن يستخدما نفس وضع FEC، وإلا لن تعمل الواجهتان أبداً، وهذا الفشل يبدو تماماً مثل حالتك: موديولان سليمان، لا إنذار، لا سجل، منفذ down.
معظم موزّعات الحزم وأجهزة الاستنساخ (taps) التي عملت معها لا تعرض أي إعداد لـ FEC إطلاقاً، مما يعني أنها تعمل بدونها والمفتاح هو الجانب الذي يجب أن يتنازل. تأكد من ذلك أولاً، ثم غيّر شيئاً واحداً.
يستحق الإضافة أن الافتراضي في CloudEngine ليس قيمة واحدة، بل يعتمد على الموديول. QSFP28-100G-LR4 وQSFP28-100G-LR1 يعملان بـ FEC مطفأة وفقاً لمعيار IEEE 802.3، بينما جميع أنواع QSFP28 الأخرى تكون افتراضياً بـ FEC مفعّلة. لذا فإن نصيحة إيقافها ببساطة خاطئة على وصلة LR4، حيث يكون المفتاح مطفأً بالفعل وعدم التطابق يعيش في الطرف الآخر.
قاعدتان أخريان من نفس الفصل وقعت فيهما:
لذا تحقق مما تحمله فعلياً بأمر
display transceiver interface 100GE1/0/1 verboseقبل أن تقرر في أي اتجاه تضبط FEC، وتذكر الالتزام (commit) في كلتا الحالتين.