NAPALM get_optics op nxos_ssh geeft alleen lane 1 DOM terug voor QSFP-100G-CWDM4 modules
Ik ben per-poort optische telemetrie aan het inbouwen in monitoring voor een paar Nexus 9000 fabrics. Het verzamelen loopt via NAPALM, en de getter die ik gebruik is get_optics().
- Nexus 9000 leaf- en spine-paren
- QSFP-100G-CWDM4 modules op de fabric-links
- NAPALM met de nxos_ssh driver, SSH-transport, nog geen NX-API ingeschakeld
Op een module met vier lanes op 100G geeft de getter precies één channel terug:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}De switch zelf heeft de data duidelijk wel - show interface transceiver details print Rx power, Tx power en bias current voor alle vier de lanes - dus dit lijkt eerder de parser dan het platform.
Wat ik gecontroleerd heb:
- zelfde resultaat op elke QSFP-100G-CWDM4 poort die ik poll, dus het is niet één rare module
- SFP+ poorten komen wel correct terug, wat logisch is als er maar één lane te rapporteren valt
- de optics-parsing van de driver doorgelezen en het lijkt erop dat alleen het eerste DOM-blok ooit wordt opgepikt
Verzamelt hier daadwerkelijk iemand per-lane DOM via NAPALM op NX-OS, of eindigt iedereen met het zelf scrapen van de switch-output?
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
Welke NAPALM-versie precies, en op welke NX-OS train draaien die leaves? De optics-code in nxos_ssh is meer dan eens herschreven, en de transceiver-output op de switch is ook niet over alle trains identiek geformatteerd, dus beide helften doen ertoe voordat iemand het een bug noemt.
Één ding de moeite waard om te doen voordat je zelf een parser gaat schrijven: roep get_optics() aan op een van de SFP+ poorten en leg die structuur naast die van de CWDM4. Komen beide terug met hetzelfde skelet en verschillen alleen de waarden, dan loopt de driver prima door de tekst heen en geeft hij het gewoon op na het eerste blok dat hij matcht. Zijn ze anders van vorm, dan komt hij bij de QSFP-poorten helemaal nooit bij het per-lane gedeelte. Dat zijn twee verschillende fixes, en de SFP+ output is de goedkoopste manier om ze uit elkaar te houden.
Actuele release van PyPI op beide collectors, en de leaves en de spines zitten op dezelfde NX-OS train, dus ik krijg overal hetzelfde terug waar ik het ook op richt - niet één rare box.
De SFP+ vergelijking gedaan die je vroeg. Zelfde skelet in beide gevallen: physical_channels.channel met één element op index 0, alle drie de waarden ingevuld. Juist antwoord voor een module met één lane, fout antwoord voor CWDM4. De parser slaagt er dus niet in om het per-lane deel van de output te vinden, hij matcht een blok, vult het in en stopt daar. Precies zoals de code eruitzag toen ik hem doorlas, ik wilde alleen dat iemand bevestigde dat ik het niet verkeerd las.
Dit is een gat in de driver en niet iets aan jouw kant. Er ligt een open pull request tegen nxos_ssh die de optics-parsing herschrijft: elke lane komt terug als eigen element onder physical_channels.channel in plaats van dat de walk stopt bij index 0, en elk element brengt zijn eigen Rx-niveau, Tx-niveau en laser bias current mee. De fixtures die erbij zitten zijn gebouwd op een QSFP-100G-CWDM4 met vier lanes, dus hij is geschreven tegen precies jouw module. Ik heb hem alleen op een labbox gedraaid, dus zie het als iets om te proberen en niet als aanbeveling voor een productiecollector.
Tot hij in een installeerbare release landt, is de pragmatische route om de getter voor 100G-poorten over te slaan en
show interface transceiver detailszelf te parsen, en daarna elke lane als eigen serie de monitoring in te duwen. Iets meer code om te onderhouden, maar je gooit dan niet driekwart van het signaal weg.Welke weg je ook kiest, alert per lane. Eén verslechterde lane op een CWDM4 trekt de hele link naar beneden zonder ooit zichtbaar te worden als je alleen lane 1 in de gaten houdt.
Per-lane zichtbaarheid doet er op Nexus meer toe dan mensen verwachten.
We liepen tegen een Cloud Scale defect aan op een Nexus 9000 met een QSFP-100G-SR4-S opgesplitst in 4x25G. Maar één van de vier 25G-poorten was gewenst, de andere drie bleven dicht, en juist die ene linkte nooit. Wat ons eruit hielp was eerst de hele groep omhoog brengen -
no shutdownop elk van de vier sub-interfaces - lane 1 laten settelen, en daarna de drie reserves weer sluiten. Houd ook FEC gelijk over de hele groep terwijl je daarmee bezig bent; een afwijkende instelling op één lane blijft niet netjes op die lane staan.Punt is: met alleen lane 1 in je dashboards ben je blind voor het grootste deel van wat een 100G-poort doet. Die extra parsing is het onderhouden waard.