NAPALM get_optics su nxos_ssh restituisce solo il DOM della lane 1 per i moduli QSFP-100G-CWDM4
Sto cablando la telemetria ottica per porta nel monitoraggio per un paio di fabric Nexus 9000. La raccolta passa attraverso NAPALM, e il getter su cui mi appoggio è get_optics().
- coppie leaf e spine Nexus 9000
- moduli QSFP-100G-CWDM4 sui link di fabric
- NAPALM con il driver nxos_ssh, trasporto SSH, NX-API non ancora abilitata
Su un modulo 100G a quattro lane il getter restituisce esattamente un canale:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}Lo switch stesso ha chiaramente i dati - show interface transceiver details stampa Rx power, Tx power e bias current per tutte e quattro le lane - quindi questo sembra il parser piuttosto che la piattaforma.
Cosa ho controllato:
- stesso risultato su ogni porta QSFP-100G-CWDM4 che interrogo, quindi non è un modulo isolato
- le porte SFP+ tornano corrette, il che ha senso quando c'è solo una lane da riportare
- ho letto il parsing delle ottiche del driver e sembra che venga preso solo il primo blocco DOM
C'è qualcuno che raccoglie davvero il DOM per lane tramite NAPALM su NX-OS, o finiscono tutti per fare scraping dell'output dello switch da soli?
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
Quale versione esatta di NAPALM, e su quale train NX-OS sono quei leaf? Il codice delle ottiche in nxos_ssh è stato rimaneggiato più di una volta, e anche l'output dei transceiver sullo switch non è formattato in modo identico tra i train, quindi entrambe le metà contano prima che qualcuno lo chiami un bug.
Una cosa da fare prima di metterti a scrivere un tuo parser: chiama get_optics() su una delle porte SFP+ e metti quella struttura accanto a quella CWDM4. Se entrambe tornano con lo stesso scheletro e solo i valori differiscono, il driver sta percorrendo il testo bene e semplicemente si ferma dopo il primo blocco che trova. Se hanno forma diversa, non arriva mai alla sezione per lane sulle porte QSFP. Sono due correzioni diverse, e l'output SFP+ è il modo più economico per distinguerle.
Release corrente da PyPI su entrambi i collector, e i leaf e gli spine stanno sullo stesso train NX-OS, quindi ottengo la stessa cosa ovunque punti - non un box isolato.
Fatto il confronto SFP+ che hai chiesto. Stesso scheletro in entrambi i casi: physical_channels.channel con un singolo elemento all'indice 0, tutti e tre i valori compilati. Risposta giusta per un modulo a una lane, risposta sbagliata per CWDM4. Quindi il parser non fallisce nel trovare la parte per lane dell'output, trova un blocco, lo compila e si ferma lì. Che è quello che sembrava il codice quando l'ho letto, volevo solo che qualcuno confermasse che non lo stavo leggendo male.
Questo è un buco nel driver piuttosto che qualcosa dal tuo lato. C'è una pull request aperta contro nxos_ssh che riscrive il parsing delle ottiche: ogni lane torna come proprio elemento sotto physical_channels.channel invece che il percorso si fermi all'indice 0, e ogni elemento porta il proprio Rx level, Tx level e laser bias current. Le fixture che ci vengono con questa sono costruite su un QSFP-100G-CWDM4 a quattro lane, quindi è stata scritta proprio contro il tuo modulo esatto. L'ho fatta girare solo su un box di laboratorio, quindi prendila come qualcosa da provare piuttosto che come una raccomandazione per un collector di produzione.
Finché non atterra in una release installabile, la strada pragmatica è saltare il getter per le porte 100G e fare il parsing di
show interface transceiver detailsda solo, poi spingere ogni lane nel monitoraggio come propria serie. Un po' più di codice da mantenere, ma smetti di buttare via tre quarti del segnale.Qualunque strada tu prenda, fai l'alert per lane. Una lane degradata su un CWDM4 trascinerà giù tutto il link senza mai farsi vedere se guardi solo la lane 1.
La visibilità per lane conta più su Nexus di quanto la gente si aspetti.
Abbiamo inciampato in un difetto Cloud Scale su un Nexus 9000 con un QSFP-100G-SR4-S diviso in 4x25G. Solo una delle quattro porte da 25G era voluta, le altre tre restavano chiuse, e quella a cui tenevamo non faceva mai link. Quello che ci ha tirato fuori è stato portare su l'intero gruppo per primo -
no shutdownsu ciascuna delle quattro sub-interface - lasciare che la lane 1 si assestasse, poi richiudere le tre di scorta. Tieni anche il FEC identico in tutto il gruppo mentre sei lì; un'impostazione anomala su una singola lane non resta educatamente su quella lane.Il punto è che con solo la lane 1 nelle tue dashboard sei cieco rispetto a gran parte di quello che sta facendo una porta 100G. Vale la pena farsi carico del parsing extra.