Logo de Oktanet Oktanet

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.

  • Integración
  • Sólo lo implementado en el código
  • Siete integraciones

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ónCisco IOS / IOS-XEFortiGateFortiSwitchJunosMerakiCisco SD-WAN
AccesoSSHAPI RESTSSHNETCONF 830Dashboard APIAPI del Manager
DiscoverySíSíSíSíSíSí
Respaldo.cfgJSON lógico por VDOM.cfgSnapshot y JSONJSON estructurado.cfg y JSON
Config Generator43 servicios16 servicios12 servicios16 serviciosIntención sin render (7 servicios)Intención sin render (9 servicios)
ComplianceTodos los tiposObjetos y métricasSíSíCarril propioSubconjunto de tipos
TopologíaCDP, LLDP, BGP, OSPF, EIGRP, FHRP, GREParticipaLLDPBGPNoBFD
Telemetría SNMPSíSíSíSíPor APIPor API cada 5 min
Gemelo: vista previaSíSíSíSíSíSí
Gemelo: aplicarSSH con diffCon banderaCon banderaCon bandera, commit confirmedCon bandera, sin DELETECon bandera, Config Groups
Red de pruebas CMLSíNoNoNoNoEdge 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 hostname y aaa hasta bgp, 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 ejemplo ntp vrf o storm-control).
  • Compliance: config_contains sobre 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_match contra 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 marca compliance=false para 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_admins y fgt_security_zones sólo en dry-run.
  • Telemetría: SNMP de CPU, memoria, sesiones e interfaces.
  • Token: credencial tipo fortigate con 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_valid porque 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 queda pending_confirm; confirmarlo es siempre de una persona. Si nadie confirma, el vigilante del scheduler revierte y el cambio queda expired. 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 job meraki_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

FabricanteQué 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
FortiGateCPU, memoria, sesiones e interfaces
FortiSwitchSistema e interfaces
JunosCPU y memoria por componente, alarmas e interfaces

Syslog y otras fuentes

  • Syslog por UDP en el puerto estándar, en modo tolerante; medición syslog con 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

TipoNombrePara qué
Toolquery_inventoryEquipos de la organización con filtros
Toolget_device_stateEstado normalizado de un equipo
Tooldiff_snapshots · list_snapshotsComparar y listar snapshots del Gemelo
Toolget_compliance_resultsResultados de cumplimiento
Toolget_routing_tableTabla de rutas observada
Toolget_topology_neighbors · get_topology_impactVecinos e impacto de un equipo
Toolget_recent_jobsJobs recientes
Tooltriage_deviceDiagnóstico resumido de un equipo
ResourceInventario, topología, resultados de compliance, snapshots y reglas vigentes de la organizaciónArtefactos como recursos
Promptdrift-triage · audit-narrative · pre-change-checkPlantillas 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

FuenteCómo entra
Guías oficiales del fabricanteSe 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.
SubidasPDF con texto (no escaneado), hasta 80 MB, indexado en segundo plano; HTML y Markdown.
Por URLSó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 OktaviaLos artículos de este portal.
Reportes de cambiosCada 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.