NAPALM get_optics liefert unter nxos_ssh nur DOM für Lane 1 bei QSFP-100G-CWDM4-Modulen
Ich bin dabei, Optik-Telemetrie pro Port für ein paar Nexus-9000-Fabrics ins Monitoring einzubinden. Die Erfassung läuft über NAPALM, und der Getter, auf den ich mich stütze, ist get_optics().
- Nexus-9000-Leaf- und -Spine-Paare
- QSFP-100G-CWDM4-Module auf den Fabric-Links
- NAPALM mit dem nxos_ssh-Treiber, SSH-Transport, NX-API noch nicht aktiviert
Bei einem Vier-Lane-100G-Modul liefert der Getter genau einen Channel zurück:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}Der Switch selbst hat die Daten eindeutig - show interface transceiver details gibt Rx Power, Tx Power und Bias-Strom für alle vier Lanes aus - das sieht also eher nach dem Parser als nach der Plattform aus.
Was ich schon geprüft habe:
- dasselbe Ergebnis auf jedem QSFP-100G-CWDM4-Port, den ich abfrage, also kein Einzelfall bei einem Modul
- SFP+-Ports kommen korrekt zurück, was Sinn ergibt, wenn nur eine Lane zu melden ist
- das Optik-Parsing im Treiber durchgelesen, und es sieht so aus, als würde nur je der erste DOM-Block aufgegriffen
Erfasst hier wirklich jemand DOM pro Lane über NAPALM auf NX-OS, oder landet am Ende doch jeder beim eigenen Scraping der Switch-Ausgabe?
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
Welche NAPALM-Version genau, und auf welchem NX-OS-Train laufen diese Leafs? Der Optik-Code in nxos_ssh wurde mehr als einmal überarbeitet, und die Transceiver-Ausgabe auf dem Switch ist über die Trains hinweg auch nicht identisch formatiert, also zählen beide Hälften, bevor jemand das einen Bug nennt.
Etwas, das sich lohnt, bevor man einen eigenen Parser schreibt: get_optics() auf einem der SFP+-Ports aufrufen und diese Struktur neben die CWDM4-Struktur legen. Kommen beide mit demselben Skelett zurück und unterscheiden sich nur die Werte, läuft der Treiber den Text sauber ab und gibt einfach nach dem ersten passenden Block auf. Sind sie unterschiedlich geformt, erreicht er den Per-Lane-Abschnitt bei den QSFP-Ports überhaupt nie. Das sind zwei verschiedene Fixes, und die SFP+-Ausgabe ist der billigste Weg, sie auseinanderzuhalten.
Aktuelles Release von PyPI auf beiden Collectoren, und die Leafs und die Spines sitzen auf demselben NX-OS-Train, ich bekomme also überall dasselbe zurück, egal wo ich hinzeige - keine einzelne komische Box.
Den SFP+-Vergleich gemacht, um den gebeten wurde. In beiden Fällen dasselbe Skelett: physical_channels.channel mit einem einzelnen Element bei Index 0, alle drei Werte gefüllt. Richtige Antwort für ein Ein-Lane-Modul, falsche Antwort für CWDM4. Der Parser findet den Per-Lane-Teil der Ausgabe also nicht etwa nicht, er matcht einen Block, füllt ihn und hört dann auf. Genau so sah der Code aus, als ich ihn durchgelesen habe, ich wollte nur, dass jemand bestätigt, dass ich ihn nicht falsch gelesen habe.
Das ist eine Lücke im Treiber und nichts, was an deiner Seite liegt. Es gibt einen offenen Pull Request gegen nxos_ssh, der das Optik-Parsing neu schreibt: Jede Lane kommt als eigenes Element unter physical_channels.channel zurück, statt dass der Durchlauf bei Index 0 stoppt, und jedes Element bringt seinen eigenen Rx-Pegel, Tx-Pegel und Laser-Bias-Strom mit. Die mitgelieferten Fixtures basieren auf einem Vier-Lane-QSFP-100G-CWDM4, er wurde also genau gegen dein Modul geschrieben. Ich habe ihn nur auf einer Lab-Box laufen lassen, also eher als etwas zum Ausprobieren behandeln denn als Empfehlung für einen Produktions-Collector.
Bis das in ein installierbares Release einfließt, ist der pragmatische Weg, den Getter für 100G-Ports zu überspringen und
show interface transceiver detailsselbst zu parsen, dann jede Lane als eigene Serie ins Monitoring zu schieben. Etwas mehr Code, den man pflegen muss, aber man wirft nicht mehr drei Viertel des Signals weg.Welchen Weg man auch wählt: pro Lane alarmieren. Eine degradierte Lane auf einem CWDM4 zieht den ganzen Link runter, ohne je aufzufallen, wenn man nur Lane 1 beobachtet.
Sichtbarkeit pro Lane ist auf Nexus wichtiger, als man erwartet.
Wir sind über einen Cloud-Scale-Defekt auf einem Nexus 9000 mit einem in 4x25G aufgesplitteten QSFP-100G-SR4-S gestolpert. Gebraucht wurde nur einer der vier 25G-Ports, die anderen drei blieben zu, und ausgerechnet der gewünschte linkte nie. Herausgeholfen hat, erst die ganze Gruppe hochzufahren -
no shutdownauf jedem der vier Sub-Interfaces -, Lane 1 sich setzen zu lassen und dann die drei überzähligen wieder herunterzufahren. Dabei auch FEC über die ganze Gruppe identisch halten; eine abweichende Einstellung auf einer einzelnen Lane bleibt nicht brav auf dieser Lane.Der Punkt ist: Mit nur Lane 1 im Dashboard ist man blind für das meiste, was ein 100G-Port tut. Das zusätzliche Parsing lohnt sich.