Probar antes de tocar producción: la red de pruebas de Oktavia

El cambio que nadie ensayó

Los cambios pequeños de configuración tienen procedimiento: ventana, revisión, respaldo. Los cambios grandes, curiosamente, casi nunca. Abrir una sucursal, cambiar los routers de un sitio por un modelo nuevo o cerrar una oficina se hacen pocas veces al año, cada vez con un ingeniero distinto, y lo que se aprendió la vez anterior está en un correo o en la memoria de alguien.

El resultado es conocido. El sitio nuevo queda arriba, pero con la numeración a mano y una lista de acceso copiada de otro sitio que ya no correspondía. El router nuevo arranca, pero un puerto quedó en la tarjeta equivocada. La sucursal cerrada sigue apareciendo en el concentrador como un vecino BGP caído durante meses, porque nadie quitó su lado del túnel.

Un cambio de ciclo de vida que no se puede ensayar se ejecuta por primera vez en producción, todas las veces.

La idea: diseñar contra la intención, probar en un gemelo, y sólo después aplicar

Oktavia parte de una fuente de verdad: el inventario y la topología que la red describe de sí misma, y sobre ellos la intención declarada de lo que cada equipo debería tener configurado. Todo cambio, desde una VLAN hasta un sitio completo, se expresa primero como un cambio a esa intención, no como comandos.

De ahí sale el mismo recorrido para todo:

• Diseñar. El cambio se propone a partir de lo que ya existe —el diseño de los otros sitios, el puerto equivalente del modelo nuevo, la numeración libre— y la persona lo edita antes de seguir.
• Probar. El gemelo digital genera la configuración que resulta de esa intención y la compara contra la del equipo. Cuando el cambio implica equipos nuevos, la red de pruebas los levanta para ensayarlo completo.
• Aprobar. Una persona revisa el diferencial exacto que se va a enviar. Nada se aplica sin esa aprobación.
• Aplicar. Con la primitiva segura de cada fabricante.
• Verificar. Una nueva auditoría, y si hace falta pruebas de conectividad, confirman que la red quedó como se declaró. Es lo que en el artículo sobre el gemelo digital llamamos cerrar el ciclo.

Dos decisiones de diseño sostienen esto. La primera: Oktavia no improvisa configuración. Lo que se envía a un equipo sale de la intención y de plantillas deterministas, y se puede leer antes de aprobarlo. La segunda: la inteligencia artificial es opcional y nunca escribe en la red. Cuando se usa, explica o diagnostica sobre un resumen acotado del equipo o del sitio, no sobre configuraciones completas.

La red de pruebas: qué hace Oktavia en CML y qué deja al operador

La red de pruebas de Oktavia hoy es Cisco Modeling Labs (CML). Ahí Oktavia arma los equipos de un cambio antes de que existan en producción, con reglas acordadas para que nunca haya duda de quién hizo qué:

• Crea nodos con un día 0 mínimo. Sólo lo necesario para entrar por SSH: nombre, interfaz de gestión y el usuario de la bóveda de credenciales, el mismo que usará en producción. En la configuración de día 0, que queda guardada en el laboratorio, va únicamente el hash de la contraseña, nunca la contraseña en claro. Todo lo demás —VLANs, ruteo, servicios, hardening— llega después por el ciclo, con prueba y aprobación.
• Cablea. Conecta el nodo nuevo a sus vecinos según el diseño, y puede agregar un PC de prueba por puerto de acceso para comprobar que los usuarios reciben dirección y salen.
• Nunca enciende un nodo. Prender es siempre decisión del operador. Oktavia sí apaga, pero sólo el equipo que sale en un reemplazo o en una baja.
• Lleva registro de cada operación. El estado de cada operación se guarda por organización, de modo que una operación interrumpida se puede reanudar donde quedó, o deshacer si falló a medias.
• Etiqueta lo que crea. Cada nodo lleva la etiqueta oktavia:device= con el nombre del equipo que representa. Así, aunque alguien mueva o renombre nodos en el laboratorio, Oktavia sabe cuál es cuál, y una baja quita exactamente lo suyo y nada más.

Antes de tocar el laboratorio, Oktavia confirma que CML está encendido y listo. Parece un detalle, y es lo que evita operaciones a medias contra un laboratorio que todavía estaba arrancando.

Ciclo de vida de sitios y equipos

Aquí está el centro del asunto. En Oktavia, abrir y cerrar sitios, y dar de alta, reemplazar y retirar equipos, no son proyectos artesanales: son flujos de un botón, cada uno con su vista previa, su aprobación y su verificación. Los ejemplos usan un laboratorio con sucursales IOS en CDMX y Monterrey y un concentrador en Guadalajara (GDL).

Alta de un sitio nuevo

Un sitio nuevo no se diseña desde cero: se clona del diseño de su tipo de sitio. Por ejemplo, una sucursal «Querétaro» con el mismo diseño que las existentes: dos routers WAN y un switch LAN, cada router con un túnel GRE y eBGP hacia su concentrador.

• Numeración propuesta y editable. Oktavia propone direcciones, VLANs, sistema autónomo y túneles libres, traducidos del sitio de referencia. La persona los revisa y los cambia si quiere; la propuesta se valida contra lo que ya está en uso antes de guardarse.
• Intención de los tres equipos y del concentrador. Se guarda la intención del sitio y, del lado del concentrador, lo que le corresponde: su vecino BGP, su túnel, su subinterfaz y la VLAN en los switches de transporte. Ese lado se aplica por el ciclo del concentrador, con su propio diferencial.
• Nodos en el laboratorio. Oktavia crea los tres nodos con su día 0 mínimo, los cablea y agrega PCs de prueba. El operador los enciende, y cada equipo entra por su alta de equipo.

Baja de un sitio

La baja es el espejo del alta, y es donde más se nota la diferencia con hacerlo a mano:

• Limpia el concentrador en orden. Arma las líneas de baja en la secuencia que no deja nada colgado: primero no neighbor en BGP, luego rutas, túnel y subinterfaz; del lado de capa 2, puerto de acceso, troncal, interfaz de VLAN y VLAN.
• Limpia Oktavia. Archiva cada equipo y luego quita su intención, su inventario, sus resultados de cumplimiento, sus reglas, su telemetría y sus llaves SSH conocidas.
• Limpia el laboratorio. Quita los nodos del sitio y sus PCs de prueba, identificados por su etiqueta.
• Valida que no quedó nada. Al final revisa Oktavia, el laboratorio y la configuración activa del concentrador, y reporta cualquier resto del sitio.

Como el alta y la baja son exactas, el ciclo es idempotente: crear, quitar y volver a crear Querétaro se puede repetir antes de cada demostración, y la red queda igual que antes cada vez.

Alta de un equipo

Un equipo nuevo, en un sitio nuevo o en uno existente, entra por un recorrido de pasos visibles: acceso (ping, puerto SSH e inicio de sesión con la credencial de la bóveda), descubrimiento y auditoría completa, encendido de la telemetría si se pide, cierre del ciclo con el gemelo digital y una verificación final con el estado de su ruteo y su cumplimiento. La configuración de puesta en marcha sale de la intención —incluidos banners, listas de acceso y la línea de consola— y sólo incluye los puertos que el modelo realmente tiene.

Reemplazo de un equipo

Cambiar un equipo por otro modelo con el mismo nombre, como un router IOSv por un Catalyst 8000v o un switch de acceso por uno de 16 puertos, se hace en tres pasos:

• Preparar. Oktavia lee los puertos del equipo actual, sugiere el mapeo al modelo nuevo y lo deja editar. La vista previa muestra qué puertos de la intención quedarían sin cubrir y cuántas referencias cambian. El nodo nuevo se crea con su día 0, sin cablear, mientras el viejo sigue en servicio.
• Cambiar. Cada enlace del equipo viejo pasa al puerto equivalente del nuevo, y el viejo se apaga. El operador enciende el nuevo y su configuración llega por el ciclo.
• Terminar. El equipo viejo se retira del laboratorio cuando el nuevo ya está encendido; la práctica es hacerlo después de su verificación.

Un reemplazo cambia la identidad SSH del equipo: misma dirección, otra llave. Oktavia guarda las llaves conocidas por organización y rechaza una llave distinta hasta que el operador confirma el cambio de forma explícita. Nunca se acepta sola, porque una llave que cambió también puede ser un equipo suplantado.

Baja de un equipo

Retirar un equipo empieza por archivarlo: un paquete descargable con su inventario, su intención, su última configuración respaldada y su cumplimiento, sin secretos. Después se quita su intención, su inventario, sus resultados de cumplimiento y su telemetría, de modo que deja de aparecer como un equipo caído en los tableros.

Pruebas de conectividad que salen de la intención

Una auditoría dice si la configuración y el estado coinciden con lo declarado. Para un sitio recién levantado hace falta también la pregunta del usuario: ¿funciona? Oktavia arma las pruebas desde la intención, sin inventar destinos:

• Por sitio: los usuarios reciben dirección por DHCP y responden, la ruta por defecto está presente, se alcanzan los otros sitios y, de forma informativa, internet.
• Por equipo: cada interfaz declarada está arriba, cada túnel responde al otro extremo, los vecinos OSPF y BGP están establecidos y la ruta por defecto existe.

Son botones opcionales, no un paso obligatorio del ciclo, y es a propósito: los primeros pings de un sitio nuevo fallan mientras el ruteo converge y los PCs piden dirección. Por eso se pueden repetir, o dejar corriendo hasta que pasen, en lugar de marcar como roto algo que sólo estaba arrancando.

Cisco SD-WAN: el mismo ciclo, a través del Manager

En una red Cisco SD-WAN la configuración no se escribe equipo por equipo: vive en el Manager. Por eso Oktavia se integra con la interfaz de programación del Manager del laboratorio en lugar de entrar por CLI a los edges, y la lógica es la misma:

• Estado del overlay. Oktavia recoge las conexiones de control, las sesiones BFD y los pares OMP, y los audita como cualquier otra regla de estado.
• Alta de un edge o de un sitio. El edge nuevo se asocia a su Config Group con variables propuestas a partir de un edge de referencia del mismo diseño, y Oktavia genera el bootstrap con el que arranca. Las credenciales se toman del lado del servidor y nunca aparecen en la vista previa.
• Segmentos LAN. Un segmento nuevo se declara como intención y el gemelo lo crea en el Config Group; su baja lo quita de todos los edges del grupo, protegiendo lo que todavía está en uso.

Diseñar, probar, aprobar, aplicar y verificar: cambia la primitiva —el Manager en lugar de la CLI— y no cambia el ciclo.

Por qué importa

• Ensayos que se repiten. Un cambio de ciclo de vida se puede ensayar tantas veces como haga falta, y deshacer, sin rehacer el laboratorio a mano.
• Demostraciones honestas. Lo que se muestra es el mismo flujo que se usa en producción, con el mismo diferencial y la misma aprobación, no una presentación preparada.
• Producción ensayada sobre su propio diseño. El sitio de prueba es un clon del diseño real, así que lo que falla en el laboratorio es lo que habría fallado en producción.
• Nada queda a medias. Altas y bajas validadas evitan los restos que ensucian el cumplimiento durante meses.

El ensayo deja de ser un proyecto aparte y pasa a ser el primer paso de cada cambio.