El signo de porcentaje no es una prueba fiable de éxito
Automatizar un cambio de configuración en Cisco IOS puede parecer sencillo: entrar en el modo de configuración, enviar los comandos, salir e informar del resultado. La dificultad está en determinar si el equipo ha aceptado la configuración prevista sin ningún error significativo.
La fuente ilustra esta limitación con Netmiko. Netmiko puede entrar y salir del modo de configuración, incluida una operación de commit cuando es necesaria, pero no detecta por sí mismo los errores de configuración.
Una solución aparentemente práctica consiste en configurar % como error_pattern de send_config_from_file. Los errores de configuración de Cisco IOS empiezan por un signo de porcentaje, así que el patrón parece ofrecer un detector de fallos sencillo.
Las pruebas de integración revelaron el problema: Cisco IOS utiliza el mismo prefijo para los errores y para las advertencias. Según la fuente, no hay ninguna forma fiable de distinguir unos de otras basándose únicamente en esa marca.
Una línea que empieza por
%indica que la automatización debe prestar atención. Por sí sola, no demuestra si el cambio completo ha fallado.
Por qué la búsqueda de patrones no basta
Un flujo que trate como fatal cualquier línea que empiece por un porcentaje puede detenerse ante una simple advertencia. Un flujo que ignore esas líneas puede pasar por alto un error de configuración real. El prefijo compartido obliga a la automatización a tomar una decisión binaria poco fiable cuando la propia salida de la CLI no ofrece una clasificación fiable.
Esto también significa que el éxito del transporte no equivale al éxito de la configuración. Entrar en el modo de configuración, enviar los comandos y volver al prompt esperado solo demuestra que la sesión ha avanzado. No demuestra que cada comando previsto haya producido el estado requerido en el equipo.
La pregunta operativa debe pasar, por tanto, de ¿Contenía el comando una cadena con aspecto de error? a ¿Ha alcanzado el equipo el estado previsto?
Un flujo de automatización más seguro
1. Capturar la interacción completa
Conserve los comandos enviados y las respuestas de la CLI sin modificar. No descarte las líneas de advertencia solo porque la sesión haya continuado y no reduzca demasiado pronto el resultado a un único indicador de éxito o fallo.
2. Tratar % como una señal de atención
Un mensaje que empieza por un porcentaje debe desencadenar una evaluación adicional, no una conclusión automática. La política de automatización puede hacer una pausa, solicitar una revisión o pasar a la validación, en función del riesgo del cambio.
3. Validar el resultado previsto
Defina las comprobaciones posteriores al cambio antes de ejecutarlo. La validación debe centrarse en el estado que el cambio debía crear, en lugar de basarse exclusivamente en el texto de las respuestas a los comandos.
Algunas preguntas útiles:
¿Está presente la configuración prevista después del cambio?
¿Sigue presente un parámetro anterior que debería haberse sustituido?
¿Han alcanzado todos los equipos objetivo el mismo estado requerido?
¿Cumple la configuración resultante la política aplicable?
4. Comparar las configuraciones antes y después
Una comparación de configuraciones aporta evidencias de lo que ha cambiado, incluidos los resultados parciales. Es especialmente importante cuando un lote contiene varios comandos y solo una parte del cambio previsto puede haberse aceptado.
5. Conservar el rastro de las decisiones
Para cada ejecución, conserve el equipo objetivo, el cambio previsto, la salida bruta de la CLI, la configuración antes y después, los resultados de la validación y la decisión final del operador o de la automatización. Estas evidencias hacen que la resolución de incidencias y la revisión de cumplimiento sean más sólidas que un mensaje genérico de tarea fallida.
6. Revertir en función de un fallo verificado
La reversión debe seguir una política explícita. Un mensaje con aspecto de advertencia puede no justificar por sí solo la vuelta atrás, mientras que una validación de estado fallida sí puede hacerlo. La configuración de referencia conocida y las evidencias que respaldan la decisión deben estar disponibles antes de iniciar la remediación.
Cómo ayuda ConnectMyAssets
ConnectMyAssets ofrece una base on-premise e independiente del fabricante para rodear de estos controles los cambios realizados por CLI:
Automatización y ZTP pueden servir como capa de ejecución de los cambios controlados. Los flujos deben incluir una validación explícita del resultado, en lugar de basarse solo en un patrón
%.Copias de seguridad e historial ofrece el versionado de las configuraciones, lo que permite comparar el estado antes y después de un cambio y utilizar la reversión en un clic cuando un fallo verificado exige una recuperación.
CMDB dinámica mantiene el inventario de los equipos gestionados en la misma plataforma operativa, lo que ayuda a los equipos a aplicar los procesos de cambio y validación a la infraestructura correcta.
Motor de cumplimiento evalúa las configuraciones frente a requisitos como NIS2, ISO 27001, PCI, CISA y NIST, de modo que la revisión posterior al cambio puede tener en cuenta tanto el cumplimiento de las políticas como la ejecución de los comandos.
Bastión SSH y Almacén de credenciales permiten un acceso administrativo controlado, sin convertir una sesión SSH correcta en una supuesta prueba de que la configuración se ha aplicado bien.
ConnectMyAssets no puede convertir en inequívoco un mensaje ambiguo de IOS. Su papel es ayudar a los equipos a gestionar el proceso que lo rodea: conservar el historial de configuración, validar el estado resultante, evaluar el cumplimiento y mantener una vía de recuperación.
La conclusión práctica
No utilice el signo de porcentaje de Cisco IOS como único criterio de fallo. Identifica la salida que merece atención, pero no puede separar de forma fiable las advertencias de los errores.
Una automatización de red fiable requiere varias capas: captura completa de la salida, validación basada en el resultado, comparación de configuraciones, conservación de evidencias y reversión regida por una política. La transcripción de la CLI es un dato para esa decisión, no el veredicto final.
Fuente: ipSpace.net
