EX4200 يبلغ عن EEPROM الخاص بـ SFP+ كمُبرمَج بشكل خاطئ بعد ترقية Junos بينما لا يزال MX960 يعرض DOM
نشغّل عددًا من روابط DWDM بمدى 80 كم من أجهزة EX4200 ببصريات من طرف ثالث على الطرفين، لأن أجزاء DWDM بعلامة المورد لم تكن لتناسب الميزانية إطلاقًا. كان هذا جيدًا لسنوات. بعد نقل أجهزة EX إلى Junos 12.3 لا تزال البصريات في نفس المنافذ ولا تزال الروابط موجودة، لكن المحول توقف عن الاعتراف بأن الوحدات هي بصريات إطلاقًا.
- EX4200، Junos 12.3 (كان DOM يعمل بشكل جيد على 11.4 في نفس الشاسيه)
- Integra SFPP-C51-80-10GD، وحدة DWDM SFP+ بمدى 80 كم
- MX960 في الطرف البعيد من نفس الرابط، نفس رقم القطعة، DOM لا يزال كاملًا
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableيطبع سجل الرسائل سطرًا واحدًا بالضبط عند إدخال الوحدة: SFP+ of type 0 EEPROM is Mis Programmed.
ما استبعدته بالفعل:
- أعدت تركيب الوحدة البصرية ونقلتها إلى منفذ آخر في نفس الشاسيه، لا تغيير؛
- جربت جهاز EX3300 احتياطي وQFX5100 في المختبر، كلاهما يتصرف بنفس الطريقة، فهذه ليست مشكلة صندوق واحد معطل؛
- تحققت من الطرف البعيد مرة أخرى، MX960 يعطي تشخيصات كاملة لنفس القطعة من نفس الطلبية.
فهل تعريف EX يفرض شيئًا في EEPROM كان الإصدار الأقدم يتجاهله ببساطة؟ وإذا كان الأمر كذلك، هل يمكن فعل شيء بالوحدة البصرية نفسها، أم أن هذا حديث يجب إجراؤه مع المورد؟
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 6
هذا السطر في السجل ليس تذمرًا عامًا، إنه التعريف يخبرك أي فحص فشل.
البايتات من 3 إلى 10 من الصفحة A0 تحمل رموز توافق الوحدة البصرية الموصوفة في SFF-8472 - البتات التي تقول 10GBASE-SR، LR، ER، ورموز SONET، ورموز Fibre Channel وهكذا. على هذا النوع من الوحدات البصرية كل البايتات الثمانية أصفار، وهذا سبب تسمية الرسالة له بالنوع 0. تتوقع المواصفة أن يكون بت واحد على الأقل في مكان ما من هذا الحقل مفعّلاً؛ حقل توافق كله أصفار ليس وصف وحدة صالحًا. كود EX القديم لم يكن يفحص هذا أبدًا وكان يمضي مباشرة لتحليل صفحة التشخيصات، بينما يتحقق التعريف الأحدث من الحقل أولاً ثم يرفض معاملة الوحدة كبصرية 10G معروفة. من هنا يأتي unknown cable وDOM المفقود. خط MX لا يشغّل هذا الفحص على نفس المسار، وهذا بالضبط سبب استمرار عمل نفس القطعة هناك.
أثبت الأمر قبل أن تجادل أحدًا: انزل إلى الصدفة (shell) وشغّل xcvrpeek page A0 على ذلك المنفذ، ثم انظر إلى الإزاحات (offsets) من 3 إلى 10. أصفار كاملة تُغلق القضية.
إصلاح الأمر في مكانه هو حيث ينهار هذا عادة. نظريًا يكتب xcvrpoke نفس تلك البايتات مرة أخرى. عمليًا يقفل الكثير من الموردين صفحة A0 وتعود الكتابة بخطأ EIO، ولا يوجد شيء يمكنك فعله حيال ذلك من جانب المحول. ما تبقى هو المورد: إما أن يشحنوا بصريات مبرمجة برموز توافق حقيقية، أو يشحنوها مع A0 غير مقفلة حتى تضبط البتات بنفسك. إذا لم يستطيعوا فعل أي منهما، فهذه مشكلة مورد ترتدي زي Junos.
شيئان يستحقان التحديد قبل أن يبدأ أحد بالتخمين.
أولاً، الإصدار الدقيق على كل جهاز. تقول إن EX انتقل إلى 12.3، لكن ماذا يشغّل MX960؟ إذا كان لا يزال على فرع أقدم فالجهازان ليسا قابلين للمقارنة فعليًا والفرق لا يخبرك بشيء بعد.
ثانيًا، هل القطعة على جانب MX هي حرفيًا نفس SFPP-C51-80-10GD من نفس الدفعة، أم نفس الطراز من طلبية مختلفة؟ الدفعات تختلف أكثر مما يرغب أي أحد.
انشر
show interfaces diagnostics opticsمن كلا الطرفين، بالإضافة إلى كل ما يطبعه سجل الرسائل عند سحب الوحدة البصرية وإعادة إدخالها، وليس فقط السطر الذي اقتبسته بالفعل.نفس القطعة على كلا الطرفين، SFPP-C51-80-10GD، نفس الطلبية، أرقام تسلسلية متتالية.
على MX960 يعطي
show interfaces diagnostics opticsالمجموعة الكاملة: درجة الحرارة، تيار انحياز الليزر، قدرة الإرسال، قدرة الاستقبال. على EX4200 نفس الأمر يطبع رأس الواجهة ثم سطر unknown cable، لا شيء آخر. إعادة إدخال الوحدة البصرية تنتجSFP+ of type 0 EEPROM is Mis Programmedفي السجل ولا شيء أكثر، بغض النظر عن أي منفذ أستخدمه.ما يزعجني هو أن نفس هذه الوحدة البصرية بالضبط في نفس هذا الشاسيه والمنفذ بالضبط كانت تبلغ عن DOM دون أي كلمة شكوى قبل الترقية.
يستحق الإضافة أن النصف للقراءة فقط من هذا موجود على الجانب الآخر من السياج أيضًا. على Cisco،
show idprom interface <if> detailيفرغ بايتات التعريف دون أي ألعاب بهلوانية في الصدفة (shell) إطلاقًا، وهو مفيد لفحص دفعة على محول احتياطي قبل أن تقترب الوحدات من صندوق Juniper.القراءة غير مؤذية في كل مكان. الكتابة من المضيف حيوان مختلف: xcvrpoke أداة داخلية، غير مدعومة كطريقة لإصلاح الوحدات، وكما ذُكر فهي محظورة بسبب قفل المورد (vendor lock) في نحو نصف الحالات على أي حال. استخدمها لإثبات ما هو خاطئ في EEPROM، ثم سلّم ذلك الإثبات لمن باعك البصريات.
نفس فئة المشكلة، عرض مختلف تمامًا، في حال وصل أحد إلى هنا من خلال بحث.
وضعنا وحدة SFP بصرية WDM من نوع BiDi بسرعة 1G بلا علامة تجارية في ge-0/0/1 من جهاز EX4600 والواجهة ببساطة لم تكن موجودة. مفقودة من
show interfaces terse، وأي أمر ضدها كان يعود بـerror: device ge-0/0/1 not found. قال السجلOPTIC State changed for port: 0/0/1ثمFibre channel transceiver plugged in without Fibre channel configuration!!. كان EEPROM مرمّزًا بحيث صنّف Junos الوحدة كوحدة إرسال واستقبال Fibre Channel بدلاً من Gigabit Ethernet، لذا لم تُنشأ واجهة Ethernet لها إطلاقًا. لا مقدار من الإعداد يصلح ذلك؛ وحدة مرمّزة بشكل صحيح تفعل.وليس هذا فقط في الطرف الرخيص من السوق. كانت هناك دفعة من وحدات Citrix ذات العلامة التجارية 10G SFP+ جعلت أجهزة NetScaler MPX وSDX تسجّل
*** Unsupported SFP+/SFP type !عند الإقلاع على أجزاء المورد نفسه. الوحدات الجيدة تحمل علامة مراجعة A2 على الملصق، والوحدات السيئة عادت عبر RMA. الترميز السيء يحدث عند كل مستوى سعر.تأكّد، وشكرًا على الإزاحات الدقيقة.
xcvrpeek على الصفحة A0 يعرض الإزاحات من 3 إلى 10 كأصفار على كل واحدة من وحدات SFPP-C51-80-10GD هذه التي فحصتها، بما فيها تلك التي لا تزال في علبها. xcvrpoke يعود مباشرة بـ EIO، إذًا A0 مقفلة ولا يوجد شيء يمكن إنقاذه من جانبنا.
عدت إلى المورد بإزاحات البايتات وسطر السجل المقتبس. قبلوا الأمر وهم يعيدون ترميز الدفعة برموز توافق حقيقية؛ تلك الجالسة في MX960 تبقى في مكانها، بما أن لا شيء على تلك المنصة يشتكي. أضع الشرح أعلاه كإجابة.