NAPALM get_optics على nxos_ssh يعيد فقط DOM المسار 1 لوحدات QSFP-100G-CWDM4
أقوم بربط قياسات بصرية لكل منفذ (per-port) في نظام المراقبة لعدد من نسيجيّ (fabrics) Nexus 9000. جمع البيانات يتم عبر NAPALM، والدالة (getter) التي أعتمد عليها هي get_optics().
- أزواج Nexus 9000 leaf وspine
- وحدات QSFP-100G-CWDM4 على روابط النسيج (fabric links)
- NAPALM مع تعريف nxos_ssh، نقل عبر SSH، لم يتم تفعيل NX-API بعد
على وحدة 100G رباعية المسارات (four-lane)، تعيد الدالة قناة واحدة بالضبط:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}السويتش نفسه لديه البيانات بوضوح - أمر show interface transceiver details يطبع Rx power وTx power وbias current لجميع المسارات الأربعة - لذا يبدو أن المشكلة في المحلل (parser) وليس في المنصة.
ما تحققت منه:
- نفس النتيجة على كل منفذ QSFP-100G-CWDM4 أستعلم عنه، لذا ليست وحدة واحدة غريبة
- منافذ SFP+ تعيد النتيجة بشكل صحيح، وهذا منطقي عندما يكون هناك مسار واحد فقط ليُبلغ عنه
- قرأت كود تحليل البصريات في التعريف (driver) ويبدو أن كتلة DOM الأولى فقط هي التي يتم التقاطها دائمًا
هل يقوم أحد فعليًا بجمع DOM لكل مسار (per-lane) عبر NAPALM على NX-OS، أم أن الجميع ينتهي بهم الأمر إلى استخراج مخرجات السويتش بأنفسهم؟
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 4
أي إصدار من NAPALM بالضبط، وعلى أي إصدار NX-OS (train) تعمل تلك الـ leaves؟ كود البصريات في nxos_ssh أُعيدت كتابته أكثر من مرة، ومخرجات الترانسيفر على السويتش ليست منسّقة بنفس الشكل عبر جميع الإصدارات أيضًا، لذا كلا الجانبين مهمان قبل أن يسميه أحد خطأً (bug).
شيء يستحق فعله قبل أن تذهب وتكتب محللك الخاص: استدعِ get_optics() على أحد منافذ SFP+ وضع تلك البنية بجانب بنية CWDM4. إذا عادت كلتاهما بنفس الهيكل واختلفت القيم فقط، فإن التعريف يقرأ النص جيدًا ويتوقف ببساطة بعد أول كتلة يطابقها. إذا كانتا مختلفتي الشكل، فهو لا يصل إطلاقًا إلى قسم لكل مسار على منافذ QSFP. هذان إصلاحان مختلفان، ومخرجات SFP+ هي أرخص طريقة للتمييز بينهما.
الإصدار الحالي من PyPI على كلا الجامعين، وكل من الـ leaves والـ spines تعمل على نفس إصدار NX-OS، لذا أحصل على نفس النتيجة أينما وجّهته - وليس جهازًا واحدًا غريبًا.
قمت بمقارنة SFP+ التي طلبتها. نفس الهيكل في كلتا الحالتين: physical_channels.channel بعنصر واحد عند index 0، وجميع القيم الثلاث معبأة. الإجابة الصحيحة لوحدة أحادية المسار، والإجابة الخاطئة لـ CWDM4. إذن المحلل لا يفشل في إيجاد جزء لكل مسار في المخرجات، بل يطابق كتلة، يملأها ويتوقف عند ذلك. وهذا ما بدا عليه الكود عندما قرأته، أردت فقط أن يؤكد أحدهم أنني لا أسيء القراءة.
هذه ثغرة في التعريف (driver) وليست شيئًا من طرفك. هناك طلب دمج (pull request) مفتوح على nxos_ssh يعيد كتابة تحليل البصريات: كل مسار يعود كعنصر خاص به تحت physical_channels.channel بدلًا من أن يتوقف المسح عند index 0، وكل عنصر يحمل مستوى Rx ومستوى Tx وbias current الخاص به. البيانات النموذجية (fixtures) المرفقة معه مبنية على QSFP-100G-CWDM4 رباعي المسارات، لذا كُتب اعتمادًا على وحدتك بالضبط. لم أجربه إلا على جهاز مختبر، لذا اعتبره شيئًا للتجربة وليس توصية لجامع بيانات إنتاجي.
حتى يصل إلى إصدار يمكنك تثبيته، الحل العملي هو تجاوز الدالة لمنافذ 100G وتحليل
show interface transceiver detailsبنفسك، ثم دفع كل مسار إلى المراقبة كسلسلة بياناته الخاصة. كود إضافي تتحمل مسؤوليته، لكنك تتوقف عن رمي ثلاثة أرباع الإشارة.أيًا كان الطريق الذي تسلكه، فعّل التنبيه لكل مسار على حدة. مسار واحد متدهور في CWDM4 سيسحب اللينك بأكمله دون أن يظهر أبدًا إذا كان المسار 1 هو كل ما تراقبه.
الرؤية لكل مسار (per-lane) مهمة على Nexus أكثر مما يتوقع الناس.
صادفنا عيبًا في Cloud Scale على Nexus 9000 مع QSFP-100G-SR4-S مقسّمة إلى 4x25G. أحد منافذ الـ25G الأربعة فقط كان مطلوبًا، والثلاثة الأخرى بقيت مغلقة، والمنفذ الذي كنا نهتم به لم يعمل أبدًا. ما أخرجنا من هذه المشكلة هو تشغيل المجموعة بأكملها أولًا -
no shutdownعلى كل من الواجهات الفرعية الأربع - وترك المسار 1 يستقر، ثم إغلاق الثلاثة الاحتياطية مرة أخرى. حافظ على FEC متطابقًا عبر المجموعة أيضًا أثناء عملك؛ إعداد غريب على مسار واحد لا يبقى بأدب على ذلك المسار فقط.المقصد هو أنه بوجود المسار 1 فقط في لوحات المراقبة الخاصة بك، أنت أعمى عن معظم ما يفعله منفذ 100G. التحليل الإضافي يستحق تحمّل مسؤوليته.