NAPALM get_optics en nxos_ssh devuelve solo el DOM del lane 1 para módulos QSFP-100G-CWDM4
Estoy conectando telemetría óptica por puerto al monitoreo para un par de fábricas Nexus 9000. La recolección corre a través de NAPALM, y el getter en el que me apoyo es get_optics().
- pares leaf y spine Nexus 9000
- módulos QSFP-100G-CWDM4 en los enlaces de fábrica
- NAPALM con el driver nxos_ssh, transporte SSH, sin NX-API habilitado todavía
En un módulo de 100G de cuatro lanes el getter devuelve exactamente un canal:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}El switch en sí claramente tiene los datos, show interface transceiver details imprime potencia de Rx, potencia de Tx y corriente de polarización del láser para las cuatro lanes, así que esto parece ser el parser más que la plataforma.
Lo que ya revisé:
- mismo resultado en cada puerto QSFP-100G-CWDM4 que consulto, así que no es un módulo raro
- los puertos SFP+ vuelven correctamente, lo cual tiene sentido cuando solo hay un lane que reportar
- leí el parsing de ópticos del driver y parece que solo se toma el primer bloque de DOM
¿Alguien está realmente recolectando DOM por lane a través de NAPALM en NX-OS, o todos terminan raspando la salida del switch por su cuenta?
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
¿Qué versión exacta de NAPALM, y qué rama de NX-OS corren esos leaf? El código de ópticos en nxos_ssh se ha reescrito más de una vez, y la salida de transceptor en el switch tampoco tiene el mismo formato entre ramas, así que ambas mitades importan antes de que alguien lo llame un bug.
Algo que vale la pena hacer antes de ponerte a escribir tu propio parser: llama get_optics() en uno de los puertos SFP+ y pon esa estructura al lado de la del CWDM4. Si ambas vuelven con el mismo esqueleto y solo difieren los valores, el driver está recorriendo bien el texto y simplemente se rinde después del primer bloque que coincide. Si tienen formas distintas, nunca llega a la sección por lane en los puertos QSFP en absoluto. Son dos arreglos distintos, y la salida SFP+ es la forma más barata de distinguirlos.
Versión actual de PyPI en ambos recolectores, y los leaf y los spine están en la misma rama de NX-OS, así que obtengo lo mismo sin importar a dónde apunte, no un equipo raro.
Hice la comparación con SFP+ que pediste. Mismo esqueleto en ambos casos: physical_channels.channel con un solo elemento en el índice 0, los tres valores llenos. Respuesta correcta para un módulo de un lane, respuesta equivocada para CWDM4. Así que el parser no está fallando en encontrar la parte por lane de la salida, coincide con un bloque, lo llena y se detiene ahí. Que es lo que parecía el código cuando lo leí, solo quería que alguien confirmara que no lo estaba leyendo mal.
Este es un hueco del driver más que algo de tu lado. Hay un pull request abierto contra nxos_ssh que reescribe el parsing de ópticos: cada lane vuelve como su propio elemento bajo physical_channels.channel en vez de que el recorrido se detenga en el índice 0, y cada elemento trae su propio nivel de Rx, nivel de Tx y corriente de polarización del láser. Los fixtures que trae están construidos sobre un QSFP-100G-CWDM4 de cuatro lanes, así que se escribió exactamente contra tu módulo. Yo solo lo he corrido en un equipo de laboratorio, así que tómalo como algo para probar y no como una recomendación para un recolector de producción.
Hasta que llegue a una versión que puedas instalar, la ruta pragmática es saltarte el getter para los puertos de 100G y parsear
show interface transceiver detailstú mismo, y luego meter cada lane al monitoreo como su propia serie. Un poco más de código que mantener, pero dejas de tirar tres cuartas partes de la señal.Vayas por donde vayas, alerta por lane. Un lane degradado en un CWDM4 va a arrastrar todo el enlace sin nunca aparecer si el lane 1 es todo lo que vigilas.
La visibilidad por lane importa más en Nexus de lo que la gente espera.
Nos topamos con un defecto de Cloud Scale en un Nexus 9000 con un QSFP-100G-SR4-S dividido en 4x25G. Solo se quería uno de los cuatro puertos de 25G, los otros tres se quedaban apagados, y el que nos interesaba nunca enlazaba. Lo que nos sacó de eso fue levantar todo el grupo primero,
no shutdownen cada una de las cuatro sub-interfaces, dejar que el lane 1 se asiente, y luego volver a apagar los tres sobrantes. Mantén también el FEC idéntico en todo el grupo mientras estás ahí; una configuración distinta en un solo lane no se queda educadamente en ese lane.El punto es que con solo el lane 1 en tus dashboards estás ciego a la mayor parte de lo que hace un puerto de 100G. Vale la pena hacerse cargo del parsing extra.