Documentación de Oktavia · Integraciones
Integraciones
Qué hace Oktavia con cada fabricante y herramienta: método de acceso, qué recolecta, qué genera, cómo aplica y con qué guardas. Cisco IOS e IOS-XE, FortiGate, FortiSwitch, Junos, Meraki, InfluxDB y Telegraf, MCP y Argos.
Cobertura por función
Lo que está implementado en la plataforma, por fabricante y por función. Para fabricantes que no aparecen aquí, consulta a Oktanet.
| Función | Cisco IOS / IOS-XE | FortiGate | FortiSwitch | Junos | Meraki | Cisco SD-WAN |
|---|---|---|---|---|---|---|
| Acceso | SSH | API REST | SSH | NETCONF 830 | Dashboard API | API del Manager |
| Discovery | Sí | Sí | Sí | Sí | Sí | Sí |
| Respaldo | .cfg | JSON lógico por VDOM | .cfg | Snapshot y JSON | JSON estructurado | .cfg y JSON |
| Config Generator | 43 servicios | 16 servicios | 12 servicios | 16 servicios | Intención sin render (7 servicios) | Intención sin render (9 servicios) |
| Compliance | Todos los tipos | Objetos y métricas | Sí | Sí | Carril propio | Subconjunto de tipos |
| Topología | CDP, LLDP, BGP, OSPF, EIGRP, FHRP, GRE | Participa | LLDP | BGP | No | BFD |
| Telemetría SNMP | Sí | Sí | Sí | Sí | Por API | Por API cada 5 min |
| Gemelo: vista previa | Sí | Sí | Sí | Sí | Sí | Sí |
| Gemelo: aplicar | SSH con diff | Con bandera | Con bandera | Con bandera, commit confirmed | Con bandera, sin DELETE | Con bandera, Config Groups |
| Red de pruebas CML | Sí | No | No | No | No | Edge C8000V |
Cisco IOS / IOS-XE
El carril más completo. Las plataformas ios e iosxe comparten plantillas y se acceden por SSH.
- Discovery: facts, interfaces, LLDP y CDP, configuración, direcciones y contadores, más el estado de BGP, OSPF, EIGRP, rutas, ARP, tabla MAC, VLAN, VTP, STP, port-security, DHCP, CPU, memoria, logging, SSH, VRF y protocolos.
- Config Generator: 43 servicios con plantilla, desde
hostnameyaaahastabgp,ospf,eigrp,acl_*,interface_acl,ip_sla,hsrp,vrrp,gre_tunnels,nat,port_hardening,vty_ssh,ntp,snmp,banners. Los de switch (vlan_database,spanning_tree,port_hardening…) y los de router (bgp,gre_tunnels,nat,ip_sla…) se restringen por rol. Las capacidades de plataforma ajustan la sintaxis por modelo y versión (por ejemplontp vrfo storm-control). - Compliance:
config_containssobre el running más todos los tipos de check de estado. - Remediación: carril
cli. La vista previa calcula la configuración de remediación línea a línea (deseado contra running); el apply va por SSH y muestra el diff antes. - Telemetría: SNMP de router y de switch: CPU a 5 segundos, 1 y 5 minutos, memoria, interfaces de 64 bits, temperatura, sensores y BGP.
- Operaciones de Argos: limpiar contadores con verificación y comprobación de servicio en vivo.
- Red de pruebas: imágenes IOSv, IOSvL2, IOL, Cat8000v y CSR1000v en CML con día 0 generado.
- Vulnerabilidades: normalización de versión de IOS e IOS-XE para el cruce con NVD, KEV y EPSS.
Credencial: tipo ssh. En equipos virtuales lentos conviene aumentar el timeout de lectura en las opciones de conexión del inventario.
FortiGate
Plataforma fortigate, carril fortigate. Oktavia habla con FortiOS por su API REST (configuración y monitor), por VDOM.
- Discovery y respaldo: snapshot por VDOM y respaldo lógico en JSON de la CMDB, además del modelo normalizado
config_model. - Intención: 16 servicios
fgt_*:fgt_system_global,fgt_dns,fgt_ntp,fgt_admins,fgt_snmp,fgt_syslog,fgt_interfaces,fgt_security_zones,fgt_address_objects,fgt_service_objects,fgt_firewall_policies,fgt_nat_policy_baseline,fgt_default_route,fgt_static_routes,fgt_bgp,fgt_ospf. Se renderizan como objetos, no como CLI. - Compliance:
config_object_matchcontra el modelo normalizado; en modo estricto, lo que sobra también es drift. Las métricas de CPU y memoria aplican por objetivos explícitos. El perfil de capacidades marcacompliance=falsepara el paso genérico. - Remediación: con la bandera de remediación del carril y una credencial con permiso de escritura. Dry-run obligatorio, respaldo lógico reciente, sólo upserts (nunca borra). 13 de los 16 servicios son remediables;
fgt_adminsyfgt_security_zonessólo en dry-run. - Telemetría: SNMP de CPU, memoria, sesiones e interfaces.
- Token: credencial tipo
fortigatecon URL base y verificación TLS; rotación y prueba de conexión desde Integraciones.
FortiSwitch
Plataforma fortiswitch, carril fortiswitch. Acceso por SSH, con lectura de la configuración completa.
- Intención: 12 servicios
fsw_*:fsw_lldp,fsw_interfaces,fsw_poe,fsw_vlans,fsw_trunks,fsw_stp,fsw_mgmt_access,fsw_admins,fsw_dns,fsw_snmp,fsw_ntp,fsw_syslog. Tienen plantilla en el Engine y se auditan como objetos. - Topología: vecinos LLDP.
- Remediación: por SSH, con la bandera de remediación del carril.
- Telemetría: SNMP de sistema e interfaces.
- Detalle: la regla de reloj lee
clock_validporque un FortiSwitch sin NTP desde la interfaz de gestión reporta 1969.
Credencial: tipo ssh.
Juniper Junos
Plataforma junos (validado en SRX), carril juniper. La fuente de verdad publica el acceso como NETCONF por el puerto 830 de forma automática.
- Discovery: operaciones nativas de NETCONF y snapshot de configuración.
- Intención: 16 servicios
jnpr_*:jnpr_management_hardening,jnpr_system_services,jnpr_login_users,jnpr_dns,jnpr_ntp,jnpr_syslog,jnpr_interfaces,jnpr_security_zones,jnpr_address_book,jnpr_applications,jnpr_security_policies,jnpr_nat,jnpr_snmp,jnpr_static_routes,jnpr_bgp,jnpr_ospf. - Remediación:
load merge→commit check→commit confirmed(10 minutos por omisión). El cambio quedapending_confirm; confirmarlo es siempre de una persona. Si nadie confirma, el vigilante del scheduler revierte y el cambio quedaexpired. Exige la bandera de remediación del carril y un respaldo reciente. - Topología: vecinos BGP. Telemetría: SNMP de CPU, memoria, alarmas e interfaces.
Credencial: tipo ssh (NETCONF usa las mismas credenciales); el usuario debe tener permiso de configuración si el carril va a aplicar.
Meraki
Plataforma meraki, carril meraki. Los equipos no se dan de alta a mano: se sincronizan desde Integraciones → Meraki con la clave de Dashboard; cada red Meraki aparece como un sitio.
- Discovery: organizaciones, redes, equipos MX, MS y MR, VLAN, firewall L3 y L7, SSID, STP, puertos de switch y topología de capa de enlace. Cámaras MV y sensores MT sólo como fuentes transversales.
- Intención: siete servicios sin render:
mx_vlans,mx_l3_firewall,ms_switch_ports,ms_stp,mr_ssids,meraki_firmware_baseline,meraki_device_tags. Se evalúan como objetos (config_object_match) en el jobmeraki_compliance, que la UI lanza junto con la auditoría. - Remediación: plan de operaciones determinista en la vista previa; apply sólo con la bandera de remediación del carril y una credencial con permiso de escritura. Nunca se ejecuta
DELETE. - Eventos push: webhooks, ubicación (location scanning) y MV Sense llegan a rutas de ingreso de la UI con token propio por organización, límites de tamaño y de tasa, y retención configurable. El registro de webhooks en Meraki se activa por bandera. Dos tareas de mantenimiento se programan con el planificador del sistema.
- Telemetría: no entra a Telegraf; sus métricas llegan por API.
Credencial: tipo meraki.
InfluxDB / Telegraf
La telemetría del plano de datos corre sobre dos servicios incluidos con el motor. Telegraf recolecta por SNMP (v2c, o v3 recomendado en producción) a intervalos cortos y recibe syslog; InfluxDB guarda las series con retención configurable.
Una instancia por organización
El recolector mantiene una configuración por organización y recarga sólo la que cambió, sin reiniciar las demás. Cada serie lleva la etiqueta tenant con la organización.
Sincronización desde el inventario
telegraf_sync genera la configuración SNMP a partir del inventario canónico y la intención (services.snmp). Incluye al equipo si existe, tiene SNMP habilitado, su lifecycle es activo, su IP resuelve y su fabricante está soportado; con probe además valida que responda a get o walk. La salida es idempotente y el reporte lista objetivos, omitidos con razón y si hace falta reiniciar. Hay una vista previa sin escribir desde Métricas.
Qué recolecta por fabricante
| Fabricante | Qué recolecta |
|---|---|
| Cisco IOS e IOS-XE (router y switch) | CPU a 5 segundos, 1 y 5 minutos; memoria; interfaces con contadores de 64 bits; temperatura y sensores; estado BGP |
| FortiGate | CPU, memoria, sesiones e interfaces |
| FortiSwitch | Sistema e interfaces |
| Junos | CPU y memoria por componente, alarmas e interfaces |
Syslog y otras fuentes
- Syslog por UDP en el puerto estándar, en modo tolerante; medición
syslogcon etiquetas de origen, severidad, facility y aplicación. - Latencia ICMP (
latency_collect) y telemetría SD-WAN (sdwan_tunnel,sdwan_event) se escriben en la misma base. - Las anomalías (cambios de estado BGP y OSPF, desviaciones de CPU y de conteo de rutas) se calculan en el motor y se consultan desde Métricas.
Consumir las métricas
La UI consulta a través del motor, por organización. Grafana puede apuntar al mismo InfluxDB como fuente de datos; no requiere nada de Oktavia. La API del motor admite también consultas Flux propias. El mapa de variables de telemetría está en la referencia; los tropiezos típicos, en Troubleshooting.
MCP / Argos
El motor expone un servidor Model Context Protocol de solo lectura sobre los artefactos de la organización. Lo consumen Argos desde la UI y asistentes de escritorio como Claude Desktop o el MCP Inspector.
Conectarlo
- Se lanza como proceso del motor en transporte stdio (la forma de registrarlo en Claude Desktop) o como servicio HTTP, según la configuración. La guía entregada con el software trae el comando exacto.
- Toda llamada exige una organización válida y permitida; los resultados tienen un límite de filas.
Lo que expone
| Tipo | Nombre | Para qué |
|---|---|---|
| Tool | query_inventory | Equipos de la organización con filtros |
| Tool | get_device_state | Estado normalizado de un equipo |
| Tool | diff_snapshots · list_snapshots | Comparar y listar snapshots del Gemelo |
| Tool | get_compliance_results | Resultados de cumplimiento |
| Tool | get_routing_table | Tabla de rutas observada |
| Tool | get_topology_neighbors · get_topology_impact | Vecinos e impacto de un equipo |
| Tool | get_recent_jobs | Jobs recientes |
| Tool | triage_device | Diagnóstico resumido de un equipo |
| Resource | Inventario, topología, resultados de compliance, snapshots y reglas vigentes de la organización | Artefactos como recursos |
| Prompt | drift-triage · audit-narrative · pre-change-check | Plantillas de análisis |
Salvaguardas
- Sin herramientas de escritura, sin acceso a equipos, sin acceso a la bóveda.
- Redacción por clave (
secret,password,community…) y por línea de configuración; los blobs de configuración se eliminan. - Cada llamada queda en un registro de evidencia por organización, con la etiqueta del cliente que la hizo; las rechazadas se registran aparte.
Argos como cliente
Del lado de la UI, Argos consume este servidor y puede conectarse a otros servidores MCP con una lista de herramientas permitidas. El proveedor de lenguaje se elige por organización: API de Anthropic o un modelo local con Ollama. Cómo trabaja Argos está en Argos y MCP.
IA local (RAG)
Recuperación aumentada que corre completa en el servidor de Oktavia. Los modelos son abiertos y los sirve Ollama: bge-m3 para los vectores y qwen2.5 de 7B para la respuesta, por omisión. Los vectores se guardan en la misma base PostgreSQL de la plataforma. Nada sale del servidor y no hay costo por pregunta. Se administra en Integraciones → IA local.
Cómo responde
- Sólo con los fragmentos recuperados, citando documento, sección y, en los PDF, página.
- Un comando de configuración se acepta sólo si aparece literal en un fragmento citado.
- Alcance por equipo, por sitio o de toda la red.
- En CPU una respuesta toma alrededor de un minuto; con GPU, mucho menos.
Corpus
| Fuente | Cómo entra |
|---|---|
| Guías oficiales del fabricante | Se seleccionan por las familias de plataforma del inventario, de fuentes verificadas con descarga permitida: hardening de Cisco IOS XE (centro de seguridad de Cisco), hardening y troubleshooting de FortiOS 7.2, troubleshooting de OSPF y BGP y políticas de seguridad de Junos, troubleshooting de Meraki MX y la guía de seguridad de infraestructura de red de la NSA. Lo de www.cisco.com, rfc-editor.org y nist.gov, que bloquean la descarga automática, lo sube un administrador. |
| Subidas | PDF con texto (no escaneado), hasta 80 MB, indexado en segundo plano; HTML y Markdown. |
| Por URL | Sólo dominios de documentación de fabricantes en lista permitida, por https, y nunca si el nombre resuelve a una dirección privada. |
| Memoria técnica (LLD) | Una por sitio; se vuelve a indexar cuando se pregunta por ese sitio. |
| Documentación de Oktavia | Los artículos de este portal. |
| Reportes de cambios | Cada veredicto del ciclo cerrado de Argos. |
Kit de documentación
Una lista de nueve elementos. Oktavia genera tres: el estándar de configuración desde la intención (con los campos secretos enmascarados), qué audita cada regla de cumplimiento y la memoria técnica por sitio. El equipo escribe cinco con plantillas en Markdown cuyas secciones «(obligatoria)» se validan al subir: estándar de diseño (HLD), runbooks de troubleshooting, procedimiento de cambios, política de seguridad de red, y circuitos y escalamiento con proveedores. El noveno son las guías del fabricante. Hay ejemplos llenos para tres redes de prueba: Cisco IOS hub-and-spoke, Cisco SD-WAN y multivendor (FortiGate, Junos y Cisco).
Salvaguardas
- Los secretos nunca se indexan: se descartan las líneas que mencionan comunidades, llaves o contraseñas.
- Agregar por URL está limitado a la lista permitida y bloquea direcciones privadas.
- Pasar una pregunta al modelo en la nube es siempre una acción explícita, marcada ✦ IA, con un resumen acotado al equipo o al sitio.
Buenas prácticas
- Fuentes oficiales y vigentes para las versiones en la red; PDF con texto, no escaneados.
- Llenar las secciones obligatorias del kit y nombrar los runbooks por el síntoma («vecino BGP caído»).
- Regenerar la parte de Oktavia después de un cambio grande de diseño.
- Para uso diario, dimensionar con GPU; en CPU funciona, más lento.