Matrices de compatibilidad, release notes y cambios de firmware

"Compatible" es una afirmación sobre una tripleta: este módulo, en esta plataforma, en esta versión de software. Los fabricantes publican esa tripleta en matrices de compatibilidad y notas de versión, y la modifican — aparece óptica nueva, la antigua se descarta, las verificaciones se vuelven más estrictas. Leer las matrices antes de comprar y releerlas antes de actualizar es el trabajo de compatibilidad más barato que existe. Esta página muestra dónde vive la información, cómo leerla, y cómo gestionar una flota para que una actualización de software no se convierta en una interrupción de óptica.

Dónde publican los fabricantes el soporte

Lea también las notas de versión del NOS que ejecuta: los cambios de óptica se ocultan bajo "problemas resueltos", "cambios de comportamiento" y "nuevo soporte de hardware".

Cómo leer una entrada de matriz

Qué cambia con el software

Una práctica de flota que evita sorpresas

1. Inventario — registrar fabricante, PN, número de serie, revisión y firmware de cada módulo por puerto (desde el conmutador o desde el banco) en el CMDB.
2. Fijar versiones — tratar la versión del NOS como parte de la tripleta de compatibilidad; no actualizar acceso y core el mismo día.
3. Leer las notas de versión en busca de elementos relacionados con la óptica antes de cada actualización.
4. Probar en un conmutador de laboratorio o canario con uno de cada tipo de óptica que use — módulos de terceros y codificados primero.
5. Conservar la imagen anterior y un plan de reversión; saber qué puertos son propensos al errdisable.
6. Línea base de DDM antes y después para que los cambios de comportamiento en la monitorización sean visibles (Monitorización).
7. Rastrear el EOL de los PN de óptica y sus sucesores para que los reemplazos coincidan con la matriz.

Óptica de terceros y codificada en este panorama

Un módulo codificado con un PN de OEM se juzga por la misma entrada de matriz que el original — la plataforma no puede distinguirlo si la codificación está completa — pero la declaración de soporte del fabricante no se extiende a él, y una verificación más estricta en una nueva versión puede exponerlo. Mantenga los módulos codificados identificables en el inventario (su fabricante y número de serie reales), pruébelos primero en las actualizaciones, y planifique para el caso en que una versión cierre la puerta (Óptica de terceros, Bloqueo de fabricante).

Lado de NIC y servidor

Los adaptadores de servidor tienen sus propias matrices (adaptador ↔ módulo ↔ controlador/firmware) y sus propias políticas — algunas familias de Intel rechazan SFP no listados a menos que un parámetro del controlador los permita; los adaptadores Mellanox/Nvidia validan cables para InfiniBand. Las actualizaciones de controlador y firmware cambian estas reglas igual que las actualizaciones del NOS (Recetas de configuración de puertos).

En CodingBox

El lado de banco de la práctica de flota: leer la identidad y la versión de firmware de cada módulo hacia la base de datos de códigos en la inspección de entrada, comparar los bytes de un módulo sospechoso con la entrada de la matriz en Check transceiver, y mantener la distinción codificado/original en las notas de la base de datos para que un rechazo el día de la actualización pueda rastrearse hasta el módulo en segundos.

Las políticas de controlador y firmware de NIC en detalle, por fabricante y sistema operativo: Compatibilidad de transceptores en NIC.

La práctica de flota como lista de verificación de puesta en marcha — actualizar antes de configurar, pruebas canario, línea base de DDM, prueba de aceptación: Selección y puesta en marcha.