NAPALM get_optics di nxos_ssh cuma balikin DOM lane 1 buat modul QSFP-100G-CWDM4
Saya lagi wiring telemetry optical per-port ke monitoring buat beberapa fabric Nexus 9000. Collection-nya jalan lewat NAPALM, dan getter yang saya andalin itu get_optics().
- pasangan Nexus 9000 leaf dan spine
- modul QSFP-100G-CWDM4 di link fabric
- NAPALM dengan driver nxos_ssh, transport SSH, NX-API belum di-enable
Di modul 100G four-lane, getter-nya balikin persis satu channel:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}Switch-nya sendiri jelas punya datanya - show interface transceiver details nge-print Rx power, Tx power, dan bias current buat keempat lane-nya - jadi ini kelihatan lebih ke parser-nya ketimbang platform-nya.
Yang udah saya cek:
- hasil yang sama di tiap port QSFP-100G-CWDM4 yang saya poll, jadi bukan satu modul yang aneh doang
- port SFP+ balik dengan benar, yang masuk akal kalau cuma ada satu lane buat dilaporin
- baca-baca optics parsing driver-nya dan kelihatannya cuma blok DOM pertama yang pernah keambil
Ada yang beneran ngumpulin DOM per-lane lewat NAPALM di NX-OS, atau semua orang berakhir scraping output switch-nya sendiri?
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 versi berapa persisnya, dan leaf-leaf itu di train NX-OS yang mana? Kode optics di nxos_ssh udah di-rework lebih dari sekali, dan output transceiver di switch-nya juga tidak diformat identik antar train, jadi dua-duanya penting sebelum ada yang nyebut ini bug.
Satu hal yang layak dikerjain sebelum kamu nulis parser sendiri: panggil get_optics() di salah satu port SFP+ dan taruh struktur itu di sebelah yang CWDM4. Kalau dua-duanya balik dengan skeleton yang sama dan cuma value-nya yang beda, driver-nya jalan bacain teksnya dengan benar dan cuma nyerah setelah block pertama yang dia cocokin. Kalau bentuknya beda, dia sama sekali tidak pernah sampai ke section per-lane di port QSFP-nya. Itu dua fix yang berbeda, dan output SFP+ itu cara paling murah buat bedain dua-duanya.
Current release dari PyPI di kedua collector, dan leaf sama spine-nya duduk di train NX-OS yang sama, jadi saya dapet hasil yang sama ke mana pun saya arahin - bukan satu box yang aneh doang.
Udah saya kerjain perbandingan SFP+ yang kamu minta. Skeleton-nya sama di kedua kasus: physical_channels.channel dengan satu elemen di index 0, ketiga value-nya keisi. Jawaban yang benar buat modul satu-lane, jawaban yang salah buat CWDM4. Jadi parser-nya bukan gagal nemuin bagian per-lane dari output-nya, dia cocokin satu block, isi itu, terus berhenti di situ. Yang persis kayak kode-nya kelihatan waktu saya baca-baca, saya cuma mau ada yang confirm saya tidak salah baca.
Ini gap di driver-nya, bukan sesuatu di sisi kamu. Ada pull request yang kebuka buat nxos_ssh yang nulis ulang optics parsing-nya: tiap lane balik sebagai elemennya sendiri di bawah physical_channels.channel, bukannya walk-nya berhenti di index 0, dan tiap elemen bawa Rx level, Tx level, dan laser bias current-nya sendiri-sendiri. Fixture yang ship bareng itu dibangun di atas QSFP-100G-CWDM4 four-lane, jadi itu ditulis persis buat modul kamu. Saya cuma pernah jalanin itu di lab box, jadi anggap itu sesuatu buat dicoba, bukan rekomendasi buat collector production.
Sampai itu landing di rilis yang bisa kamu install, jalur praktisnya itu skip getter-nya buat port 100G dan parse
show interface transceiver detailssendiri, terus push tiap lane ke monitoring sebagai series-nya sendiri-sendiri. Kode yang harus kamu urus jadi agak lebih banyak, tapi kamu berhenti buang tiga perempat sinyalnya.Jalan mana pun yang kamu pilih, alert-nya per lane. Satu lane yang degraded di CWDM4 bakal narik seluruh link ke bawah tanpa pernah kelihatan kalau cuma lane 1 yang kamu pantau.
Visibility per-lane itu lebih penting di Nexus daripada yang orang kira.
Kami kesandung defect Cloud Scale di Nexus 9000 dengan QSFP-100G-SR4-S yang di-split jadi 4x25G. Cuma satu dari empat port 25G yang diinginin, tiga lainnya tetap shut, dan yang kami butuhin tidak pernah link. Yang ngeluarin kami dari situ itu naikin seluruh grup duluan -
no shutdowndi tiap empat sub-interface-nya - biarin lane 1 settle, terus shut lagi tiga yang spare. Jaga FEC-nya tetap identik di seluruh grup selagi kamu di situ juga; setting yang aneh di satu lane doang tidak bakal sopan-sopan tinggal di lane itu doang.Intinya, dengan cuma lane 1 di dashboard kamu, kamu buta ke sebagian besar apa yang lagi dikerjain port 100G-nya. Parsing ekstra itu worth buat diurus.