Un SFP+ DWDM de terceros se queda caído en un Arista 7050T con EOS 4.10.6: ¿hay algo antes de parchear la imagen?

Antes de que alguien te mande a la imagen, dos cosas.

¿A qué tren de EOS estás realmente atado en ese 7050T? Si tiene que quedarse en 4.10.6, entonces un hack específico de ese build es al menos coherente. Si puedes moverlo, ten en cuenta que el manejo de transceptores se reorganizó en versiones posteriores y ninguna receta escrita para 4.10.6 se traslada.

Y ¿qué puede realmente grabar ese proveedor en ellos? Vale la pena preguntar si su programador siquiera trae un perfil de Arista, o solo la codificación Cisco por plataforma que la mayoría mantiene, las piezas de ASR9K, por ejemplo, necesitan su propio perfil y los proveedores de ópticos sí mantienen uno. Que recodifiquen el lote sale mucho más barato que vivir con una imagen modificada. Por separado: ¿ya le pediste a tu equipo de cuenta la clave de unsupported-transceiver, o eso está descartado por temas comerciales?

El parche de imagen sí funciona en ese build exacto, y no es mucho trabajo, pero hazlo en un equipo de laboratorio o de repuesto, nunca en algo que lleve tráfico.

En resumen: descomprime EOS-4.10.6.swi y conserva los miembros, que son boot0, initrd-i386, linux-i386, rootfs-i386.sqsh y version. Descomprime el sistema de archivos raíz como root, edita el agente, vuelve a empaquetar:

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

La edición en sí está en squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: comenta las cuatro líneas cerca de la línea 172 que verifican el estado de presencia y luego ejecutan la autenticación del transceptor. El -Z store del zip no es opcional, el swi tiene que quedar sin comprimir o el equipo no lo va a arrancar.

Después de eso los puertos suben con lo que sea que conectes, porque ya nada está validando. Dos precios: te quedas sin soporte del fabricante en una imagen modificada, y el parche está atado a este build, así que conserva el .swi original en la flash para volver a arrancar ahí cuando algo salga mal.

Para responder las preguntas de arriba: el equipo es de repuesto y no tiene contrato de soporte, y el proveedor no tiene ningún perfil de Arista en su programador, ellos codifican para plataformas Cisco y ahí termina la lista, así que recodificar este lote no está sobre la mesa. La vía del equipo de cuenta no está descartada, simplemente no me ayuda esta semana.

Reconstruí la 4.10.6 como se describió, arranqué la imagen parcheada, y los dos puertos DWDM subieron al primer intento. La imagen original sigue en la flash. El enlace ha estado estable desde entonces, y el extremo remoto no ve nada raro.

Me alegra que haya funcionado, pero sé honesto contigo mismo sobre la vida útil de ese parche, porque el hilo de arriba lo hace sonar más general de lo que es.

Está escrito para 4.10.6 y nada más. Han preguntado cómo repetirlo en 4.14.5F, 4.14.7M y 4.23.8M y nadie ha publicado nunca una respuesta que funcione, porque el gestor de transceptores se reorganizó en las versiones posteriores y esas cuatro líneas no están ahí esperándote. Cada actualización también reemplaza la imagen, así que el parche desaparece y los puertos se caen la próxima vez que alguien haga mantenimiento de rutina.

Las rutas que sobreviven a una actualización son la clave service unsupported-transceiver específica del cliente que emite el equipo de cuenta, y en las plataformas más antiguas el archivo marcador enable3px. Usa la imagen parcheada para mantener útil un equipo viejo, no como estándar para la red.

La misma pelea del lado de Cisco, con un detalle que vale la pena traer aquí. SFP+ DWDM de 80 km de terceros (Pro10Optix, etiquetados SFP-10G-DWDM-192) venían funcionando sin problemas en switches Catalyst 6500. Al moverlos a los puertos SFP+ integrados de un ASR 9001 con IOS XR 5.3.3 dieron:

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

LED de puerto en rojo, interfaz caída, estado reportado como pérdida de enlace o baja luz sin loopback, la longitud de onda se leía como 0 nm y el láser nunca se encendía. transceiver permit pid all en la interfaz no cambió nada por sí solo, y el service unsupported-transceiver global encima de eso tampoco rescató ese lote. La plataforma espera un número de parte con la forma DWDM-SFP10G-xx.yy de su propia matriz de ópticos, y un PID genérico no mapea a ningún óptico soportado, así que no hay nada que el override pueda relajar.

Alguien más en la misma versión tenía módulos Skylane SPDTU080100D139 de 80 km funcionando en un 9001, pero solo con ambos comandos configurados, de lo contrario la interfaz no se recuperaba después de una caída del enlace. El lote defectuoso finalmente se cambió por módulos correctamente codificados.

Agrego algo que ahorra una vuelta cuando regreses con un proveedor: pídeles que codifiquen para la plataforma, no para la marca. Una gran parte de estos hilos son módulos que se identifican como el vendedor correcto pero llevan un número de parte que la matriz de la plataforma nunca ha visto, y los overrides tipo permit solo relajan la verificación para módulos que de otra forma parecen correctos ante el equipo.

Mientras tengan los módulos en el banco, pídeles que confirmen que la EEPROM cumple estrictamente con SFF-8472. Datos de A2h descuidados se leen como algo sin sentido, la longitud de onda de 0 nm mencionada arriba es exactamente ese tipo de caso, y una vez que la lectura esté limpia y la plataforma siga rechazando la pieza, tienes algo concreto para el soporte del proveedor en vez de un argumento general sobre ópticos de terceros.