Una ConnectX-4 MCX456A-ECAT no enlaza con un Cisco NCS en 100GBASE-LR4 mientras el loopback pasa en ambos extremos
Llevamos un par de racks que entregan tráfico a un Cisco NCS de cara al operador, y uno de los uplinks de servidor de 100G nunca ha subido desde que se montó. Mismo resultado tras mover el servidor a otro armario con un panel de parcheo distinto, así que he dejado de tratarlo como algo puntual.
- Servidor Supermicro, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, ambos puertos libres
- QSFP28 100GBASE-LR4 genérico, monomodo, alcance de 10 km, uno en cada extremo
- Cisco NCS en el otro lado, fibra oscura entre las dos salas
La parte que me tiene atascado: cada módulo pasa un loopback en su propio equipo. Con la fibra conectada de vuelta al mismo QSFP28, la NIC reporta un enlace limpio de 100G, y el NCS hace lo mismo de su lado. Pon el tramo real en medio y no hay nada.
# módulo en loopback en la propia NIC
Speed: 100000Mb/s
Link detected: yes
# mismo módulo, tramo real hacia el NCS
Speed: Unknown!
Link detected: noLo que ya hemos probado:
- cambiamos ambos módulos por repuestos del mismo lote, sin cambios
- movimos el servidor y volvimos a parchear por un panel distinto
- abrimos un caso con el fabricante de la NIC, y la respuesta fue un enlace a la lista de transceptores validados en las notas de la versión del firmware, que no explica por qué el loopback funciona
¿Hay algo en el LR4 en la ConnectX-4 que le permita enlazar localmente pero nunca a través de un tramo real, o estoy persiguiendo el extremo equivocado de esto?
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 3
Esto suena a un trayecto sucio, no a un problema de compatibilidad.
Todo lo que has reemplazado hasta ahora está en el lado que ya probó estar bien, por eso nada cambió - el propio tramo es lo único que sigue sin tocar. Así que trabaja el trayecto:
La lista de transceptores validados que te señalaron vale la pena mirarla, pero un módulo que sube limpiamente en loopback ya está siendo manejado correctamente por la NIC. Las listas de compatibilidad explican módulos que se rechazan de plano, no módulos que enlazan localmente y mueren a lo largo de un tramo.
Si limpiar no lo resuelve, el siguiente paso es una fuente de luz y un power meter en la fibra oscura, o un OTDR si puedes conseguir uno prestado, antes de comprar otra NIC u otro par de ópticos.
Un loopback solo demuestra que un puerto puede oírse a sí mismo - láser, receptor, ajustes de velocidad. No dice nada sobre el vidrio entre tus dos salas, y esa es la única pieza que no has probado. Así que antes de volver a culpar a la NIC, saca números de ambos extremos con el tramo real conectado: ¿cuál es la potencia Rx en el puerto del NCS, y cuál en la NIC? Una Rx por debajo del umbral Low Warn con el tramo puesto es el indicio clásico hacia el extremo lejano o hacia el trayecto, más que hacia el puerto local. En el lado Linux
ethtool -mdebería darte la misma lectura, y si te devuelveCannot get module EEPROM information: Input/output errorno lo leas como un módulo muerto - en mlx5 eso suele ser el acceso al módulo por el lado del firmware, ymst start,mst cable addy luegomlxcableste darán los valores de todos modos.La limpieza fue la respuesta. Pusimos un microscopio en las caras de extremo y ambos módulos más ambos latiguillos estaban contaminados; el latiguillo que pasaba por el panel entre salas era el peor de los dos. Limpiamos todo en el trayecto, reasentamos, y el enlace de 100G hacia el NCS subió al primer intento y se ha mantenido desde entonces.
Un poco molesto conmigo mismo por haber pasado tanto tiempo en el ángulo de la compatibilidad cuando el resultado del loopback me estaba diciendo todo el rato que los módulos estaban bien y el trayecto no. Para quien llegue aquí más tarde: el loopback prueba el puerto, no la fibra.