Skip to content

Core Concepts

How OLAV NetOps collects, stores, and reasons about your network.

Feature Claims

ID Claim Status
C-NE-05 Each snapshot produces a unique snapshot_id shared across all tables ⬜ Pending
C-NE-06 Custom TextFSM templates take priority over built-in NTC templates πŸ”Ά Env-Blocked
C-NE-07 CommandRegistry.reload() picks up new templates without restart ⬜ Pending

Data Flow

graph LR
    A[Network Devices] -->|SSH + show commands| B[Raw CLI Output]
    B -->|TextFSM parse| C[netops.parsed_outputs]
    C -->|Auto-views| D[v_bgp_neighbors_auto<br/>v_ospf_neighbors_auto<br/>v_interfaces_auto<br/>...]
    C -->|Topology ETL| E[netops.topology_links]
    D --> F[Agent Queries]
    E --> F

Every collection run produces a snapshot β€” a point-in-time capture of all device state. Each row in the database carries a snapshot_id that ties it back to the exact collection moment.

Snapshot Model

A snapshot is the fundamental unit of network state. When you run /netops_init or trigger a manual collection, OLAV:

  1. Collects β€” SSH to every device in nornir/hosts.yaml, runs all whitelisted show commands
  2. Parses β€” Applies TextFSM templates to extract structured fields from raw CLI output
  3. Stores β€” Writes parsed JSON arrays to netops.parsed_outputs, raw text to netops.raw_output_store
  4. Derives β€” Auto-generates views (v_*_auto) and topology links from the parsed data

All rows from the same collection share the same snapshot_id. This makes time-series comparison simple: pick two snapshot IDs and diff any table.

TextFSM Template Priority

When parsing CLI output, OLAV looks for a matching template in this order:

Priority Location Source
1 (highest) workspace/ops/config/textfsm/ User-defined overrides
2 workspace/ops/config/templates/custom/ Generated by /learn_cmd
3 workspace/ops/config/templates/ Bundled defaults
4 (lowest) ntc-templates Python package Community templates

The first match wins. To override a built-in template, place a file with the same naming convention (<platform>_<command>.textfsm) in priority 1 or 2.

Agent Hierarchy

graph TD
    User -->|"olav '...'"| Quick[Quick Agent<br/>fast queries, single iteration]
    User -->|"olav --agent ops '...'"| Ops[Ops Orchestrator]
    User -->|"olav --agent audit '...'"| Audit[Audit Orchestrator]
    Ops --> Analysis[Analysis<br/>routing + simulation]
    Ops --> Probe[Probe<br/>live device checks]
    Ops --> Diff[Diff<br/>drift detection]
    Ops --> Lab[Lab<br/>digital twin]
    Audit --> Designer[Designer<br/>create profiles]
    Audit --> Auditor[Auditor<br/>execute + report]
Agent When to use Device access?
Quick Simple questions, daily lookups Yes (single CLI)
Ops β†’ Analysis What-if simulation, path analysis No (pure computation)
Ops β†’ Probe Batch liveness checks, parallel CLI Yes (parallel)
Ops β†’ Diff Compare two snapshots for changes No (DB queries)
Ops β†’ Lab Pre-deployment validation in ContainerLab CLAB API only
Audit Compliance checks, health reports No (DB queries)

Command Safety

Every CLI command executed on a network device passes through two gates:

  1. Whitelist β€” Only commands registered in the commands table (populated during /netops_init) are allowed
  2. Blacklist β€” Regex patterns in blacklisted_commands.yaml are rejected even if whitelisted

This ensures agents cannot run arbitrary commands on production devices. See Configuration for details on managing these lists.