وحدة SFP+ أصلية 160-9103-900 تظهر بحالة UCTF على Ciena 3930 - أين قائمة الوحدات المعتمدة
أقوم بتشغيل تسليم 10G لعميل على جهاز 3930 كان موجودًا في الموقع بالفعل. الوحدة من إنتاج Ciena نفسها، مأخوذة من مخزوننا، والمنفذ يعمل فعلًا - لكن حالة التشغيل هي UCTF بدلًا من Ena، وينذر التنبيه الخاص بوحدة غير معتمدة (uncertified transceiver) بشكل دائم. اختبار القبول يتطلب قائمة تنبيهات نظيفة، لذا لا يمكنني تسليم العمل بهذا الشكل.
- Ciena 3930، بالبرنامج كما وصل إلى الموقع
- Ciena 160-9103-900 SFP+ 10G
- زوج أحادي النمط إلى وحدة NTU الخاصة بالعميل، مسافة قصيرة
> port xcvr show
Port 1 ... Oper State: UCTF
ما جربته:
- أعدت تركيب الوحدة ونقلتها إلى منفذ آخر، نفس النتيجة
- ركّبت وحدة ثانية من 160-9103-900 من نفس المخزون، نفس حالة UCTF تمامًا
- تأكدت أن الرابط ينقل حركة المرور بالفعل، فليست هذه مشكلة بصرية
توقعت أن تكون وحدة تحمل علامة Ciena في محول Ciena هي التوليفة الوحيدة التي لا تُعارَض أبدًا. كيف أعرف أي طرازات وحدات يعتمدها فعلًا البرنامج المشغَّل حاليًا، وما الذي يجعل حالة عدم الاعتماد تختفي؟
Comments 4
هذا بالضبط ما يحدث، ويوقع الناس لأن الجميع يفترض أن الفحص يتعلق بالمصنّع. ليس كذلك. ما يقارنه المحول هو الترميز الذي تحمله الوحدة مقابل قائمة الطرازات التي يعتمدها إصدار برنامجه نفسه. وحدة من صنع Ciena لكن طرازها غير موجود في تلك القائمة تظهر بحالة UCTF، بينما وحدة من مورّد وحدات متوافقة يطابق ترميزها إدخالًا في القائمة تظهر نظيفة.
إذن سير العمل هو:
خذ إدخالًا من الأمر الأول يطابق السرعة والمدى اللذين تحتاجهما، ووفّر وحدات مرمّزة على أساسه. واجهنا نفس حالة UCTF على جهاز 3930 وركّبنا وحدة ModuleTek 10G LR SFP+ مرمّزة كـ XCVR-S10V31، وهي ضمن القائمة المعتمدة - فعمل المنفذ بحالة تشغيل Ena دون أي إشارة عدم اعتماد، ولم يُلمَس أي شيء آخر في المحول.
تحذيرات تستحق الذكر قبل التسليم للعميل: هذه مطابقة ترميز وليست تصريح دعم من المورّد، فإذا كان الجهاز تحت عقد، تحقق مما يقوله الاتفاق بشأن الوحدات الضوئية من غير Ciena قبل تصميم الحل عليها. الطريق الآخر هو إصدار برنامج يدرج 160-9103-900، لكن على خدمة عميل حية، الترقية عادة ما تكون الخيار الأعلى تكلفة بين الاثنين.
شغّل
port xcvr show supportedوابحث عن طرازك في المخرجات. يعرض هذا الأمر الطرازات ومعدلات الخط التي يوافق الإصدار المثبت على الجهاز على اعتمادها، وهذه القائمة هي الشيء الوحيد المُعتدّ به هنا - وليس ما هو مطبوع على المقبس.انشر ما يظهر، أو على الأقل ما إذا كان 160-9103-900 موجودًا فيه. إذا لم يكن كذلك، فلديك الجواب بالفعل، وكون الوحدة أصلية من Ciena لا علاقة له بالأمر. يستحق الذكر أيضًا إصدار SAOS الذي يعمل عليه جهاز 3930 - فالقائمة خاصة بكل إصدار، وجهاز جالس في الموقع منذ فترة قد يسبق بسهولة رقم قطعة تدرجه برامج لاحقة.
شغّلته. القائمة طويلة، لكن 160-9103-900 غير موجود فيها - راجعتها مرتين. البرنامج هو نفسه الذي جاء به الجهاز، لم يلمس أحد الإصدار منذ التركيب، و
port xcvr showما زال يضع المنفذ في حالة UCTF.إذن قطعة أصلية من Ciena غير معتمدة على محول Ciena لأن هذا الإصدار لا يدرجها. ليس الجواب الذي توقعته، لكنه يفسر لماذا تصرفت الوحدة الثانية من نفس المخزون بنفس الطريقة.
يستحق الأمر إضافة حالة فشل ليست فيها مشكلة الترميز هي السبب، لأن ملاحقة الترميز مكلفة. على جهاز ME3600X يعمل بإصدار 15.3(1)S واجهت
%PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not supportedوحالة err-disable من نوع gbic-invalid على وحدات 10G. الأمرانservice unsupported-transceiverوno errdisable detect cause gbic-invalidلم يغيّرا شيئًا، ولم تظهر الوحدات إطلاقًا فيshow inventory، وshow interfaceلم يطبع أي نوع وسيط (media type) على الإطلاق، ومقياس بصري لم يرصد أي ضوء خارج منها. كانت دفعة معطوبة - وحدات مأخوذة من جهاز ME3600 آخر يعمل بالفعل نجحت فورًا. لا نوع وسيط مع لا ضوء إرسال يعني عتادًا معطوبًا، ولا يمكن لأي أمر فك حظر أن ينقذ ذلك.وعلى الطرف الآخر من الطيف، الترميز الخاطئ للمنصة تحديدًا: وحدات DWDM SFP+ بمدى 80 كم من طرف ثالث في جهاز ASR 9001 بقيت down بمعرّف PID عام، ولم ينقذها
transceiver permit pid all، لأن IOS XR أراد PID بصيغة DWDM-SFP10G-xx.yy من مصفوفة الوحدات الضوئية الخاصة بتلك المنصة. أعاد المورّد ترميز الدفعة فعملت. حالتك تقع بين الاثنتين: الترميز صحيح، إنه فقط غير مدرج في قائمة هذا الإصدار.