Los ópticos SFP+ de terceros se quedan caídos en un DCS-7150S-24 de segunda mano: ¿el archivo enable3px en flash sigue siendo una opción?
Conseguí un par de switches Arista de segunda mano para el laboratorio y me topé directo con la barrera de ópticos. Los módulos codificados por Arista enlazan, los cables DAC pasivos enlazan, y cualquier cosa de terceros deja el puerto caído.
El lado del laboratorio:
- DCS-7150S-24, comprado usado, sin contrato de soporte ni equipo de cuenta detrás de mí
- módulos SFP+ de terceros variados
- cables DAC pasivos para los tramos cortos dentro del rack
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upLo que ya deduje hasta ahora:
- que el DAC suba mientras los ópticos no me dice que esto es una verificación de codificación, no cableado ni una jaula muerta
- hay un comando de configuración de la forma
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, que obviamente quiere una clave que no tengo forma de conseguir - artículos más antiguos mencionan un archivo marcador en la flash en vez de una clave, pero no puedo saber a qué generación aplica eso
¿Cuál de los dos mecanismos es el que corresponde a un equipo de esta edad, y el archivo en flash sigue siendo una opción en un 7150S, o la clave es la única ruta que queda?
Comments 6
En esa generación es el archivo, y es tan tosco como suena. Desde el CLI de EOS:
Un archivo vacío, nada dentro, su mera presencia activa los ópticos de terceros después del reload. La lista de plataformas donde esto funciona es larga: DCS-7120T-4S, la familia DCS-7050 y toda la línea DCS-7150S entre otras, y cada modelo tiene una versión de EOS más reciente que todavía respeta el archivo, que va más o menos desde 4.13.16M en los equipos más viejos hasta la rama 4.23 en el 7150S. Los switches más nuevos ignoran el archivo por completo.
Así que un 7150S-24 está del lado bueno de esa línea, siempre que no hayas pasado de lo que soporta el modelo. Pruébalo antes de acercarte siquiera a la ruta de la clave.
¿Qué rama de EOS tiene ese 7150S-24, y lo actualizaste después de comprarlo? Eso importa, porque el corte es por plataforma más que por familia. El archivo marcador está documentado como funcional en el 7048T, el 7120T-4S, el 7140T-8S, las variantes SFP+ 7124 y 7148, la serie 7050 y 7150S y las tarjetas de línea 7548S-LC, pero la última versión de EOS que todavía lo respeta difiere para cada uno.
Si ya actualizaste EOS en un equipo usado, hay una buena posibilidad de que te hayas actualizado fuera del truco, y entonces el arreglo barato es bajar de rama en vez de andar buscando una clave.
Nunca toqué EOS desde que llegó el equipo, así que sigue en la rama que dejó el vendedor, lo cual resultó ser una suerte. Hice el touch, write memory, reload, y los módulos SFP+ de terceros que antes estaban muertos ahora suben como puertos normales. Sin clave, sin equipo de cuenta, nada más necesario. Los DAC siguieron funcionando todo el tiempo, como se esperaba.
Para cualquiera que llegue aquí con un equipo más nuevo: el archivo genuinamente se ignora ahí, y la única vía es una clave criptográfica por cliente que vive en la configuración en ejecución como
La clave viene del equipo de cuenta o de ventas, no del soporte, TAC no está autorizado a emitir claves de desbloqueo y te va a mandar de vuelta a la gestión de cuenta, lo cual es un callejón sin salida cuando el switch salió del mercado de segunda mano.
Vale la pena repetirlo para montajes de laboratorio: los cables DAC pasivos se aceptan por defecto sin importar el estado de desbloqueo. Si los tramos son lo bastante cortos, puedes esquivar toda la pregunta cableando con DAC y guardando los ópticos para los enlaces que realmente los necesiten.
Pequeña corrección a "vive en la configuración en ejecución": en el código más antiguo con el que trabajé también había una variante sin documentar del mismo comando, así que si te topas con una referencia que no coincide con la sintaxis de arriba, viene de ahí y no de que alguien lo haya escrito mal.
En mi experiencia la clave también surtía efecto sin reinicio, la mayoría de los ópticos de terceros empezaban a funcionar justo después de ingresar el comando, aunque un par de módulos seguían negándose pasara lo que pasara. Eso fue hace un tiempo en hardware que ya no tengo, así que revísalo en tu propio equipo antes de planear una ventana de mantenimiento en torno a eso.
Ya que esta comparación sale cada vez que sale el tema: en Cisco IOS-XE y IOS XR el equivalente son dos pasos en vez de uno. El comando global por sí solo no basta, también necesitas el de por interfaz en cada puerto físico que deba aceptar el módulo:
La línea por interfaz es la que salta la verificación de product-ID, así que el puerto al menos va a intentar encender el óptico, sin garantía de que el módulo luego funcione, solo de que la plataforma deja de rechazarlo. Lo he hecho en IOS XR 5.3.3 y en equipos IOS-XE.
La advertencia es la misma en ambos fabricantes, y es la razón por la que la gente sigue discutiendo esto: si una falla se rastrea hasta un transceptor de terceros instalado por el cliente, el soporte bajo garantía o contrato puede negarse. Bien para un laboratorio, una decisión que vale la pena tomar a conciencia en producción.