Oktavia
Multi-vendor network automation

1. Executive summary

Oktavia is a network automation platform for enterprise IT operations. It pairs an automation engine with a unified web interface to run audits, verify configuration compliance, visualize network state, and manage changes in a controlled and traceable way.

It is built for teams that need to move fast without giving up control. Every action produces versioned artifacts, every change requires prior validation, and everything lands in a searchable history.

2. The problem it solves

Enterprise networks grow more complex faster than the teams that run them. The symptoms repeat across almost every customer:

• Manual audits that take days and depend on nobody misreading a configuration.
• Configuration drift that goes unnoticed until there is an incident.
• Fragmented visibility across inventory, compliance, topology, and metrics, each in its own tool.
• No traceability on who changed what, when, and with whose approval.
• Reactive operations: the team acts when a user reports, not when the network drifts.
• Diagnosis without closure: audit tools find the problem, but fixing it stays manual work outside the tool.

3. Value proposition

4. Capability categories

Oktavia capabilities group into seven categories. It is the way to read the platform by problem solved, not by screen.

5. Platform modules

6. The closed loop

This is what separates Oktavia from an audit tool. Finding a problem is worthless if fixing it stays manual, and applying a change blind is worthless if nobody verifies it landed right. The loop is a single path walked without leaving the platform:

1. Audit the chosen scope: a device, a role, a site, or the whole network.
2. Read the compliance result: what failed, at what severity, and which configuration lines are missing.
3. Propose the change against declared intent, not against a generic template.
4. Review the diff between desired and live configuration in the Digital Twin, with estimated impact.
5. Approve. A person, always. No change applies on its own.
6. Apply using each vendor safe primitive.
7. Verify: audit again and confirm the finding closed.

Every step leaves a downloadable artifact and lands in the job history. If the result is not convincing, there is a way back.

Before and after verification

The verdict is not just «the rule passes now». Oktavia compares each device's test results before and after the change and splits them into fixed, regressions, new failures, and still failing. A regression prevents closing the loop. State failures that already existed before the change are shown separately and do not block it, because the change did not cause them.

Argos also closes the loop on changes that already exist in the Digital Twin, such as a security patch prepared by the automatic flow; a verified patch is marked as such. Every verdict is indexed as a change report in the local AI, so the next similar change starts from what was already learned.

How it applies on each vendor

7. New service rollout

The same cycle rolls out services, not just corrects deviations. You describe what you want and Oktavia proposes it as declared intent:

• A tunnel between two sites, with the routes that run through it, and its complete teardown when the project ends.
• Advertising a network: logical interface, OSPF announcement, access control lists, and BGP on the site edge devices, with ping verification.
• Editing routing: router identifier from the logical interface, recommended site summarization.
• DHCP for a VLAN, with the range proposed from what Oktavia already knows about the segment.
• Adopting what exists: read a device backup and declare as intent what it already has configured, so auditing can start without redesigning anything.

8. Site and device lifecycle

Opening and closing sites, and onboarding, replacing and retiring devices, are one-button flows with preview, approval and verification. Each is first rehearsed on the test network (Cisco Modeling Labs), where Oktavia creates the nodes with a minimal day 0 and wires them; powering them on is always the operator's call.

• Site creation: the design of its site type is cloned, with proposed and editable addressing, the hub side (BGP, tunnel, subinterface, VLAN), and the lab nodes and test PCs.
• Site removal: cleans the hub in order (BGP no neighbor, tunnels, subinterfaces, VLANs and trunks), cleans Oktavia and the lab, and validates that nothing of the site is left. Create, remove and create again is repeatable.
• Device onboarding: access with the vault credential, discovery and audit, configuration from intent, telemetry, loop and verification.
• Device replacement: a different model under the same name, editable port mapping, link cutover, and the old device retired once the new one is powered on and in service (the practice is to verify it before retiring the old one). The new SSH key is accepted only with operator confirmation.
• Device retirement: a downloadable archive package without secrets, and cleanup of intent, inventory, compliance and telemetry.

On Cisco SD-WAN the same loop goes through the Manager: edge onboarding with its Config Group and bootstrap, and creation and removal of LAN segments. The details are in the article Test before you touch production: the Oktavia test network.

9. Argos, the network ChatOps

Argos is the assistant embedded in every Oktavia screen. You ask in plain language and it answers with network data, not generalities. It covers four moments of daily work:

• Understand: network state, compliance, what to address first, diagnosis of a device or a site.
• Investigate: path between two IP addresses forward and back, correlation of failures against configuration, anomaly and unreachable device detection.
• Configure: describe the service in plain language or paste the configuration, and Argos proposes it as declared intent for the operator to edit before applying.
• Close the loop: audit, read compliance, take it to the Digital Twin, approve, and verify. Each step is a button, not a sentence you have to type.

Two design principles separate it from a generic assistant. Every answer states whether it consumed the language model or resolved deterministically, so the cost is visible before you click. And no action that touches the network happens without a person approving it.

What uses AI and what does not

Most of what Argos does never touches the model: they are queries and calculations over already collected data, with reproducible results. The model steps in when something has to be written, prioritized, or interpreted from free text.

The pattern repeats: the data is computed first, and the model only writes or prioritizes on that result. It never invents findings, it works with the ones the calculation produced.

Every action carries a visible badge before you click: ⚙ IAOps is deterministic, ◆ IA local (local AI) runs on the Oktavia server without sending anything or consuming tokens, and ✦ IA uses the cloud model with its per-query cost.

10. Local AI and documentation

Argos answers with network data; the local AI adds what the documentation says. It is a retrieval-augmented generation (RAG) system that runs entirely on the customer's Oktavia server: the models are open and served with Ollama —bge-m3 for embeddings and qwen2.5 7B for generation, by default— and the vectors are stored in the platform's own PostgreSQL database. Nothing leaves the server and there are no per-question tokens.

The business overview, with the flow diagram and an Argos video: Local AI with your company's context.

How it answers

• Only from what was retrieved. The answer is built from the retrieved fragments and cites them: document, section and, for PDFs, page.
• Verbatim commands only. A configuration command is accepted only if it appears verbatim in a cited fragment; no syntax is invented.
• Bounded scope. The question is asked about a device, a site, or the whole network, and retrieval is limited to that scope.
• Secrets are never indexed. Lines mentioning communities, keys, or passwords are dropped, and the configuration standard is generated with secret fields masked.
• Response time. On CPU an answer takes roughly a minute; a GPU makes it much faster.

What it indexes

Documentation kit

In Integrations → Local AI, a nine-item checklist shows what documentation the network has and what is missing. Part of it is generated by Oktavia: the configuration standard from the intent, what each compliance rule audits, and the technical report per site. The rest is written by the team with Markdown templates whose «(obligatoria)» (mandatory) sections are validated on upload: design standard (HLD), troubleshooting runbooks, change procedure, network security policy, and circuits and provider escalation. The ninth item is the vendor guides. The kit ships filled examples for three test networks: Cisco IOS hub-and-spoke, Cisco SD-WAN, and multi-vendor with FortiGate, Junos and Cisco.

Where it is used

• Argos questions that start with «according to the documentation…».
• «What the documentation says» for each incident in the diagnosis.
• «How to remediate · Local AI» on each CVE: it reads the vendor advisory and extracts the fix and the mitigations.

Good practices

• Curate the sources. Official, current guides for the versions running in the network; an old or third-party document produces old or foreign answers.
• Text PDFs. A scanned PDF has no text to retrieve; convert it before uploading.
• Fill the kit's mandatory sections. They answer the most questions and they are validated on upload.
• Name runbooks after the symptom («BGP neighbor down», «tunnel without traffic»), which is how people ask during an incident.
• Regenerate Oktavia's part —standard, rules, and technical report— after a major design change.
• Size the server. It works on CPU at roughly a minute per answer; for daily use, a GPU is worth it.
• Escalate to the cloud only explicitly. Sending a question to the cloud model is a visible action, marked ✦ IA, and only a summary bounded to the device or site travels, not the document base.
• Do not upload secrets. The system drops lines with credentials, but good practice is for documents not to carry them.

11. Security and service inventory

Network security

Security posture computed on the collected configuration of firewalls and switches, across four domains: perimeter, management plane, identities, and segmentation. Each finding carries the configuration line backing it and its recommendation in the vendor own syntax. It includes a global and per-device score, and filters by domain and severity.

Vulnerabilities by version

Each device's software version is matched against NVD, CISA KEV and FIRST EPSS: actively exploited vulnerabilities first, with a rating per device, site and tenant, the minimum safe version per model that feeds the software standard, and a printable CVE report per network or site. Lab images are marked as approximate and do not count as real exposure. More in the article Security in Oktavia and Argos.

What to address first

A list of CVEs is not a decision. Argos crosses each exploited or likely vulnerability with the device's running configuration —whether the vulnerable feature is enabled— and with its role in the network, and classifies it as act now, plan, watch or confirm version. An edge device with the feature exposed goes first; an internal one with the feature off, later. The score runs from 0 to 100, higher is better, with bands, and CVEs can be filtered by site or device.

PCI DSS network report per site

For the sites in scope of the cardholder data environment —the point-of-sale sites—, Oktavia builds the PCI DSS v4.0.1 network report on requirements 1, 2, 6.3.3, 7, 8, and 10. Each requirement is met, not met, or not evaluated, and it only counts if the device's vendor family has a check for it. It carries evidence per device and comes out as a printable PDF. It supports the QSA's work; it does not replace it.

Remediation and security patches

• How to remediate. The local AI reads the vendor advisory and extracts the fixed version and the mitigation.
• Urgent change. It becomes a draft in the Digital Twin, in the «Security patches» category, with its board: proposed, approved, applied, verified when the lines appear in the backup, and fixed when the CVE disappears.
• Declare in the Configurator. When the mitigation line is a field of the standard —HTTP server off, SSH v2, VTY SSH only, SNMP views, password encryption, spanning-tree mode, logging trap—, it is written to the device's intent and compliance watches it from then on. Lines carrying a secret stay pending for the vault.
• Security patches flow. With a button, or by asking Argos to «prepare the security patches», it takes the exploited or critical CVEs whose feature is enabled, prepares the drafts and the standard proposals, and notifies. It never applies: approval stays human.

Hardening standard by role

The security standard is declared once, in the role, and every device with that role inherits it, existing and new: logging to the collector, restricted read-only SNMP, NTP, management access over SSH only, and unnecessary services turned off. Other scopes keep only what varies per site or per device. Compliance checks what is missing and, on Cisco IOS, also what is extra; the Digital Twin proposes the fix and a person approves it.

Service inventory

It answers the question that comes before compliance: what is configured on each device, and how much of it is declared as intent. It cross-checks what is observed against what is declared and against the service catalog, and classifies each service into four states, along with the configuration scope that defines it.

From the inventory itself, blind spots are declared as intent in a single step, without touching the network: what was already there simply starts being audited.

12. Per-vendor coverage

13. Integrations

Oktavia was designed to coexist with the customer ecosystem, not to replace it. It can feed and be fed by the tools already in operation.

Integration differentiator: Oktavia contributes the intent and compliance layer, the standard the network is compared against, which a metrics dashboard or a traditional monitoring system does not have. They measure; Oktavia also validates against a standard and automates the response.

14. Architecture and operating model

The platform separates the web interface from the automation engine. The interface owns the user experience, tenant organization, and persistence; the engine executes against the devices. They talk over a REST API authenticated with a key.

• Persistence: relational database with per-tenant data separation.
• Artifacts: JSON, CSV, and configuration files, downloadable and versioned.
• Deployment: orchestrated containers, on customer premises or in a private cloud.
• Device access: SSH, NETCONF, and native vendor API, with credentials encrypted in a vault.

Operating model

• Everything runs as asynchronous jobs with complete history.
• Every job produces versioned artifacts, downloadable.
• No direct changes are ever applied without generating and validating artifacts first.
• Remediation actions are supervised and traceable, with an identified approver.

15. Platform security

Oktavia has read access and, when the customer authorizes it, change access to their network. Its own security is part of the scope, not an annex.

Where the data lives

The platform is deployed on the customer infrastructure, on premises or in their private cloud. Inventory, configurations, and artifacts do not leave it. The only exception is AI analysis: when an action that consumes the model runs, the content that query needs travels to the AI provider. Argos states before every action whether it will consume it, so the decision is the operator's, case by case, and the deterministic capabilities cover most of the work without sending anything. The local AI, marked ◆ IA local, runs on the same server and sends nothing either; its index never stores secrets.

Device credentials

They are stored encrypted at rest in the database, with a key that lives in the deployment configuration and not in the code. They are never shown in the interface nor written to logs. We recommend read-only credentials for discovery, and separate change credentials only if remediation is in scope.

Access to the platform

Mandatory login, integrated with the corporate identity provider. On top of that, an access allowlist by IP address or network, managed from the interface itself, with two modes: monitor, which logs rejections without blocking, and strict, which blocks. Switching to strict is guarded: it cannot be enabled if the operator own address is not covered. The same list applies to the web interface and to the automation engine.

Data separation

Multi-tenant with row-level separation: every query is scoped to the user organization. One customer data is not reachable from another customer session, not even through a programming mistake.

Between components

The web interface and the automation engine authenticate with a key on every call, in both directions. The engine exposes no operation without it.

Scoped API keys

An external integration never receives the interface key: it gets its own key, scoped to one organization, read or write, and to a closed list of operations. It is revoked without touching the others.

No change without approval

This is a security property too, not only a process one: no action that writes to the network happens without a person approving it, and every application is recorded with its approver, its diff, and its artifact.

Corporate identity and second factor

Login integrates with the customer identity provider over OpenID Connect. Oktavia supports Okta, and with it single sign-on and whatever second factor the provider policy already enforces: onboarding, offboarding, and passwords live where the corporate directory already lives, with no parallel user list to maintain. Local passwords are kept for contingency only.

The platform can also require the authentication to be recent, not merely that a session exists at the provider: it can demand a fresh authentication event, restrict the accepted methods, a passkey for example, and require a specific assurance level, such as the Okta two-factor one. That is what makes closing the browser ask for the second factor again.

16. Integration requirements

To deploy Oktavia over an existing network we ask the customer for:

• Base device inventory.
• List of sites and site types.
• Operational roles per device.
• Vendor, platform, and version, where the data exists.
• Management addresses and access method.
• Read credentials for discovery.
• Change credentials, if remediation is in scope.
• Backups or available live configuration.
• Current configuration standards.
• Operational constraints and change windows.
• Approvers and technical contacts.

Minimum data per device

Identity (hostname, management address, site, role), operating system and model, interfaces, layer 2 discovery neighbors, BGP and OSPF neighbors where they exist, live configuration or backup, and the baseline operational services: NTP, DNS, SNMP, SSH, banners, and time zone.

Preferred order for sourcing the data

1. Native vendor API.
2. NETCONF, RESTCONF, or remote procedure calls.
3. Structured vendor parsers.
4. Command-line output parsing.
5. Live configuration or backups.

Server for Oktavia

Oktavia runs on a single Linux x86_64 server (Ubuntu 22.04 or 24.04 LTS recommended) with Docker and Docker Compose v2, physical or virtual, on premises or in the customer's cloud. The figures are estimates for sizing the machine: they depend on the number of interfaces per device, how often audits run, and how long telemetry is kept.

Oktavia Pro includes inventory and discovery, configuration and state compliance, the Digital Twin with approved remediation, backups, and Argos.

Oktavia Pro with Telemetry and Event Orchestration adds SNMP collection every 30 seconds, syslog reception, the time-series database with 7 days of retention, and the always-on event evaluator.

Considerations

• Telemetry disk grows with the interfaces per device and with retention: keeping 30 days instead of 7 multiplies that part by four.
• Backups and audit results grow with audit frequency; the retention policy is agreed during implementation.
• Argos with a cloud AI provider needs no extra resources. The local AI needs at least 16 GB of additional RAM and, preferably, a GPU: on CPU an answer takes roughly a minute.
• Connectivity: the server must reach the devices' management plane (SSH, HTTPS/API, NETCONF, and SNMP depending on the vendor) and receive syslog (UDP 514) if telemetry is enabled. Users reach the console over HTTPS.

17. Implementation process

1. Data onboarding. Receive the base inventory, normalize names, roles, sites, platforms, and models, and load the initial file.
2. Controlled discovery. Validate reachability, run discovery in batches, collect backups, and normalize the observed inventory.
3. Intent baseline. Define services per scope, load service variables, enable compliance checks, and configure the customer service catalog.
4. Validation. Run the full audit, review the dashboards, and tune rules and exceptions.
5. Operation and remediation. Propose the change, simulate it, approve it, apply it, and recompute compliance to confirm closure.

Estimated time to a working deployment

18. Licensing

The complete platform is Oktavia Pro. Continuous telemetry and event orchestration are licensed separately because they have a different consumption profile, they store time series and run a permanent evaluator, and not every network needs them on day one.

Oktavia Pro

Multi-vendor discovery, inventory, configuration and state compliance, desired configuration per device and per scope, the full remediation cycle with Digital Twin, new service rollout with rollback, topology with path tracing and firewall policy analysis, network security, service inventory, IP Intelligence, configuration backups, advanced reports, provisioning, scheduled operations, FinOps, multi-tenant, and the complete Argos with the local AI.

Telemetry and Event Orchestration

Real-time metrics, telemetry dashboards compatible with Grafana, and the event automation engine: condition-to-action rules that react automatically to BGP session drops, OSPF neighbor drops, interfaces down, and CPU, memory, temperature, and error thresholds.

Included with every license: support and updates

While the license is active, every Oktavia deployment receives the platform's security patches, updates and new features, at no extra cost.

19. Use cases

• Configuration compliance audit across multiple sites in minutes.
• Automatic detection of configuration drift after a maintenance window.
• Desired configuration generation for new devices by role and by site.
• Live path trace between two points with next hop, egress interface, and asymmetry detection.
• Capacity visibility on wide area interfaces before saturation.
• Post-maintenance connectivity validation across the whole network.
• Change control with a diff between desired and live configuration before applying.
• Onboarding a new network with site types and sites configured before the first discovery run.
• Firewall security posture with the configuration evidence backing each finding.
• Discovering which services are configured and audited by nobody, and declaring them without touching the network.
• Knowing whether a flow passes: which firewall policy decides it at each hop, with its address translation and its logging.
• Locating an IP address down to the access port by crossing the ARP table with the MAC table.
• Adopting the configuration a device already has as declared intent, to start auditing it without redesigning anything.
• Fixing a deviation end to end: propose, approve, apply, and verify it closed.
• Bringing up a tunnel between two sites with its routes, and tearing it down completely when the project ends.
• Advertising a new network in OSPF and BGP on the site edge devices, with ping verification included.
• Asking what the runbook or the vendor guide says during an incident, with the citation, without the documentation leaving the server.
• Preparing the PCI DSS network report for the point-of-sale sites, with evidence per device, for the QSA's review.
• Turning exploited CVEs with the feature enabled into security patches ready for approval, and verifying the CVE disappeared.