NAPALM get_optics on nxos_ssh returns only lane 1 DOM for QSFP-100G-CWDM4 modules
I am wiring per-port optical telemetry into monitoring for a couple of Nexus 9000 fabrics. Collection runs through NAPALM, and the getter I lean on is get_optics().
- Nexus 9000 leaf and spine pairs
- QSFP-100G-CWDM4 modules on the fabric links
- NAPALM with the nxos_ssh driver, SSH transport, no NX-API enabled yet
On a four-lane 100G module the getter hands back exactly one channel:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}The switch itself clearly has the data - show interface transceiver details prints Rx power, Tx power and bias current for all four lanes - so this looks like the parser rather than the platform.
What I have checked:
- same result on every QSFP-100G-CWDM4 port I poll, so it is not one odd module
- SFP+ ports come back correctly, which makes sense when there is only one lane to report
- read through the driver's optics parsing and it looks like only the first DOM block ever gets picked up
Is anyone actually collecting per-lane DOM through NAPALM on NX-OS, or does everyone end up scraping the switch output themselves?
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
Which NAPALM version exactly, and which NX-OS train are those leaves on? The optics code in nxos_ssh has been reworked more than once, and the transceiver output on the switch is not formatted identically across trains either, so both halves matter before anyone calls it a bug.
One thing worth doing before you go and write your own parser: call get_optics() on one of the SFP+ ports and put that structure next to the CWDM4 one. If both come back with the same skeleton and only the values differ, the driver is walking the text fine and simply gives up after the first block it matches. If they are shaped differently, it never reaches the per-lane section on the QSFP ports at all. Those are two different fixes, and the SFP+ output is the cheapest way to tell them apart.
Current release off PyPI on both collectors, and the leaves and the spines sit on the same NX-OS train, so I get the same thing back wherever I point it - not one odd box.
Did the SFP+ comparison you asked for. Same skeleton in both cases: physical_channels.channel with a single element at index 0, all three values filled in. Right answer for a one-lane module, wrong answer for CWDM4. So the parser is not failing to find the per-lane part of the output, it matches a block, fills it in and stops there. Which is what the code looked like when I read through it, I just wanted someone to confirm I was not misreading it.
This is a gap in the driver rather than anything on your side. There is an open pull request against nxos_ssh that rewrites the optics parsing: every lane comes back as its own element under physical_channels.channel instead of the walk stopping at index 0, and each element brings its own Rx level, Tx level and laser bias current. The fixtures that ship with it are built on a four-lane QSFP-100G-CWDM4, so it was written against your exact module. I have only run it on a lab box, so take it as something to try rather than as a recommendation for a production collector.
Until it lands in a release you can install, the pragmatic route is to skip the getter for 100G ports and parse
show interface transceiver detailsyourself, then push every lane into monitoring as its own series. A bit more code to own, but you stop throwing away three quarters of the signal.Whichever way you go, alert per lane. One degraded lane on a CWDM4 will drag the whole link without ever showing up if lane 1 is all you watch.
Per-lane visibility matters more on Nexus than people expect.
We tripped over a Cloud Scale defect on a Nexus 9000 with a QSFP-100G-SR4-S split into 4x25G. Only one of the four 25G ports was wanted, the other three stayed shut, and the one we cared about never linked. What got us out of it was bringing the whole group up first -
no shutdownon each of the four sub-interfaces - letting lane 1 settle, then shutting the three spares again. Keep FEC identical across the group while you are in there as well; an odd setting on a single lane does not politely stay on that lane.Point being, with only lane 1 in your dashboards you are blind to most of what a 100G port is doing. The extra parsing is worth owning.