Guía de intención para ingenieros de red

1. Para quién es esta guía

Para ingenieros de red y de automatización, de cliente o de socio, que diseñan y mantienen la intención de una red en Oktavia. Sirve para cualquier dominio: Campus, WAN, Seguridad, Gestión y, en proveedores de servicios, Transporte y Servicios de cliente.

Al terminar sabrás en qué alcance va cada valor, cómo leer y editar la intención desde la consola de tu dominio, cuándo usar el Configurador y cómo llevar un cambio a la red sin saltarte ningún control.

No hace falta programar. Sí ayuda saber leer JSON, y aquí se explica lo necesario.

2. La idea: declarar, no teclear

En Oktavia no se escriben comandos por equipo: se declara cómo debe ser la red. Esa declaración es la intención y es la fuente de verdad. Tiene dos caras:

Editar la intención no toca la red. Guardar sólo cambia lo que la red debería ser; por eso, tras guardar, la auditoría mostrará como falla lo que todavía no llega a los equipos. El cambio viaja por un ciclo con aprobación humana (sección 10).

3. Dónde se trabaja

Es la misma intención vista desde cuatro lugares. Lo que guardas en uno aparece en los demás.

4. Los dominios

Cada servicio del catálogo pertenece a un dominio, y cada dominio tiene su consola con las mismas pestañas: Resumen, Intención, Reglas, Cumplimiento, Cambios, Flujos y Telemetría. Un ingeniero de WAN trabaja en WAN sin ver lo demás, y el Alcance de arriba recorta todo a un sitio.

Centro de datos y nube se sumarán como dominios con la misma forma de trabajo: lo que aprendas aquí aplica igual.

5. Alcances: dónde va cada valor

La intención se declara una vez, en el alcance más general posible, y los equipos la heredan. Es la decisión de diseño más importante: un buen alcance evita cientos de excepciones.

Las capas se aplican en ese orden y la última gana. Así funciona la mezcla:

• Los objetos se mezclan campo por campo. Lo que un alcance no menciona sigue llegando de arriba.
• Las listas se reemplazan completas. Nunca se suman.
• "enabled": false apaga el servicio para los equipos de ese alcance.

defaults              ntp.servers = ["192.0.2.1", "192.0.2.2"]
by_role / wan_router  ntp.servers = ["198.51.100.9"]

wan_router  →  ["198.51.100.9"]
lan_switch  →  ["192.0.2.1", "192.0.2.2"]

El router recibe un servidor, no tres: su lista reemplazó a la de arriba.

6. Editar desde la consola del dominio

Es la forma más directa de ver y cambiar tu intención. Abre Servicios, elige el dominio y entra a Intención.

Leer la tabla

Hay una fila por valor, agrupada por declaración: Servicio, Alcance, Parámetro y Valor. La etiqueta del alcance dice a cuántos equipos les gana:

• Gana en N equipos: esa declaración es la que aplican.
• Sin efecto: un alcance más específico le gana en todos sus equipos. Conviene revisarla.
• Deshabilitado: tiene enabled: false.

Con el Alcance de arriba eliges un sitio y la tabla muestra sólo lo que aplica a sus equipos, cada valor desde la declaración que les gana, sin importar en qué capa esté. Es la mejor forma de responder «¿qué tiene realmente este sitio?». El buscador encuentra servicios, parámetros y valores.

Cambiar un valor

1. Busca el servicio y pulsa Editar valores en la declaración que quieres cambiar. Si eliges mal el alcance, cambiarás a más equipos o a menos de los que crees.
2. Edita el JSON que se abre.
3. Pulsa Revisar el cambio. Oktavia valida y muestra cada valor antes y después, y cuántos equipos quedan afectados.
4. Si es correcto, pulsa Guardar en la intención. Las reglas de cumplimiento y la configuración esperada se actualizan.
5. Usa el botón que aparece para llevarlo a la red con Argos.

7. El JSON que estás editando

Cada declaración es un objeto con los campos del servicio. Este es un ntp:

{
  "servers": ["192.0.2.1", "192.0.2.2"],
  "source_interface": "Loopback0",
  "vrf": "Mgmt"
}

Y una lista de objetos, como vlan_database, lleva un elemento por VLAN. La tabla muestra cada uno en su fila:

{
  "entries": [
    { "id": 100, "name": "data" },
    { "id": 200, "name": "voice" }
  ]
}

Reglas al editar:

• Escribe sólo lo que este alcance define. Lo demás se hereda. Copiar valores heredados los congela aquí, y el estándar deja de llegar.
• Agregar a una lista es reescribirla: pon los elementos existentes y el nuevo.
• Para volver a heredar, quita la declaración desde el Configurador. Si quieres que un equipo no tenga algo heredado, apaga el servicio con "enabled": false o declara el valor que sí debe tener.

Secretos

Las claves nunca se ven ni se escriben en claro. En pantalla aparecen como ••••; déjalas así y Oktavia conserva el valor guardado. Para una clave nueva, guárdala en la bóveda de credenciales y usa su referencia:

{ "address": "203.0.113.2", "remote_as": 64501, "password": "<<vault:bgp>>" }

Si escribes un secreto en claro, Oktavia rechaza el guardado y te pide la referencia.

8. Cuándo usar el Configurador

Abre el Configurador cuando vayas a:

• Declarar un servicio por primera vez o llevarlo a otro alcance. Los formularios del catálogo guían cada campo.
• Revisar dónde está declarado algo en todos los alcances, con su estado efectivo o sombreado.
• Previsualizar las líneas que un equipo recibiría.
• Importar o exportar: propuestas JSON, CSV y la intención completa.
• Ordenar: la Estandarización sube a un alcance común lo que está repetido en muchos equipos, y separa lo que sólo ordena de lo que cambia equipos.

Al guardar, escribe sólo los campos que tocaste. Y si vas a tapar listas heredadas, te avisa cuáles antes de hacerlo: léelo.

Traer una red que ya existe

No hace falta empezar en blanco. Argos compara lo declarado con lo que tienen los equipos y lleva a la intención lo que está configurado pero sin declarar, leyendo sus respaldos. Queda como propuesta para revisar. Ojo: importar no es aprobar. Si un equipo tiene un error y lo importas, se vuelve intención.

9. La intención de estado

La pestaña Reglas de cada consola muestra cómo debe estar funcionando la red, también en una tabla: regla, resultado, equipo, parámetro y valor esperado, con lo que falla primero. Al elegir un sitio verás sus equipos y sus resultados.

• Automática de la config: Oktavia la deriva de tu intención. Si declaras un túnel, la regla exige que esté arriba. No se edita: cambia al editar la config.
• Manual: la defines tú en Reglas de cumplimiento, por ejemplo un umbral.
• Fijada a mano: una automática que alguien fijó; ya no sigue a la config.

Las reglas de configuración, una por servicio declarado, están en el plegable de abajo. Comparan la configuración del equipo con tu intención.

10. Llevar el cambio a la red

Después de guardar, la consola ofrece la frase de Argos para cerrar el ciclo. Todo cambio sigue el mismo camino:

1. Auditar. Oktavia compara la intención con los equipos y encuentra lo que falta.
2. Proponer. Cada diferencia se vuelve un cambio con ticket en el Gemelo digital, con su diferencia y su rollback.
3. Revisar y aprobar. Una persona lo aprueba; se puede probar antes sin aplicar.
4. Aplicar y verificar. Una nueva auditoría confirma que el equipo quedó como la intención.

En un núcleo IOS XR el cambio es una sola transacción de red con commit confirmed: si no confirmas, los equipos regresan solos.

11. Recetas por dominio

Gestión · Cambiar los servidores NTP de toda la red

1. En Gestión → Intención, busca NTP. Sin elegir sitio, verás todas sus declaraciones.
2. Edita la de defaults con la lista completa de servidores.
3. Si aparecen declaraciones en otros alcances, decide con quien corresponda si son excepciones reales. Las que no, quítalas en el Configurador para que hereden.

Campus · Agregar una VLAN a un sitio

1. En Campus → Intención, elige el sitio y busca VLAN.
2. Edita la declaración que gana en sus switches y agrega el elemento a entries, conservando los existentes.
3. Si la VLAN debe cruzar enlaces entre switches, revisa también sus trunks.
4. Después comprueba en Servicios de Capa 2 en qué switches vive y en qué gateway termina.

WAN · Agregar un vecino BGP

1. En WAN → Intención, elige el sitio y busca BGP. Los vecinos casi siempre viven en by_device.
2. Agrega el vecino a la lista, con su clave como referencia a la bóveda.
3. Revisa si hacen falta prefix-lists o route-maps.
4. Al cerrar el ciclo, comprueba la adyacencia en Servicios de Capa 3 y el camino en Análisis de ruteo.

Seguridad · Ajustar una ACL

1. En Seguridad → Intención, busca la ACL. Si está en un alcance común, cambiarla afecta a todos los equipos que muestra la etiqueta.
2. Para un solo equipo, no toques la común: declárala en su by_device con la lista completa.

Servicios (proveedor) · Dar ancho de banda a un cliente

1. En Servicios → Intención, edita l3vpn o l2vpn y agrega bandwidth_mbps al sitio o circuito del cliente.
2. Con el servicio xr_qos declarado en el rol pe, Oktavia deriva la política.
3. Lleva el cambio al núcleo como transacción de red y revisa el servicio en Servicios de cliente.

12. Buenas prácticas

• Empieza por lo más general. Baja de alcance sólo cuando haya una razón.
• by_device es para lo que es del equipo: IP, interfaces, vecinos y excepciones acordadas.
• Diseña por tipo de sitio para que los sitios nuevos nazcan iguales.
• Lee «a cuántos equipos» antes de guardar. Si el número te sorprende, no guardes.
• Revisa lo que dice «Sin efecto». Una declaración que no gana en ningún equipo confunde al siguiente ingeniero.
• Nada de secretos en claro. Todo por la bóveda.
• Estandariza antes de endurecer. Si el blindaje se hace con todo en by_device, el estándar del rol nunca existe.
• Verifica con cumplimiento, no con la memoria. Un cambio termina cuando la auditoría lo confirma.

Para profundizar: cuándo usar cada alcance, la referencia de Service Vars y las consolas por dominio.