Lab Agent¶

The Lab Agent (ops-lab) deploys and configures virtual network labs using ContainerLab and Nokia SR Linux. It operates exclusively on lab infrastructure — it has no access to production devices.

Feature Claims

ID	Claim	Status
C-NE-28	`deploy_lab` builds ContainerLab topology from snapshot data	🔶 Env-Blocked
C-NE-29	Lab agent pushes SRL config and verifies BGP/OSPF convergence	🔶 Env-Blocked
C-NE-30	`deploy_lab` auto-handles SRL topology.yml quirks and veth injection	🔶 Env-Blocked
C-NE-31	Lab agent has no `execute_cli` — no live device access	⬜ Pending

When to Use¶

"Deploy a lab replica of R1-R4 and test a config change"
"Push eBGP config to the lab and verify convergence"
"Simulate a link failure in a safe environment before production rollout"
"Validate routing policy changes in ContainerLab before applying live"

Tools¶

Tool	Purpose
`run_python_simulation`	Generate topology YAML from snapshot data
`deploy_lab`	Deploy ContainerLab topology + apply SRL workarounds
`push_node_config`	Push SR Linux CLI config to a specific lab node
`save_lab_config`	Save node configuration to a file for review
`exec_on_node`	Execute a read-only command on a node for verification
`deploy_and_push_lab`	Combined: deploy topology + push all node configs atomically

No execute_cli

The Lab Agent does not include execute_cli. It cannot SSH to production devices (192.168.100.x). All operations target the ContainerLab server only.

How It Works¶

Step 1 — Generate Topology¶

run_python_simulation takes snapshot data and produces a ContainerLab topology YAML:

run_python_simulation(
    simulation_type="topology_from_snapshot",
    snapshot_id="<latest>",
    config={}
)
# Returns: {"yaml": "...", "nodes": [...], "links": [...]}

Step 2 — Deploy Lab¶

deploy_lab sends the YAML to the ContainerLab API and applies mandatory post-deploy steps:

deploy_lab(
    yaml_content: str,     # topology YAML from run_python_simulation
    ssh_host: str,         # SSH host for veth injection (default: auto-resolved)
    wait_seconds: int      # seconds to wait after fix (default: 40)
)

Internally executes three steps:

POST /api/v1/labs — Deploy topology via ContainerLab HTTP API
fix_srl_topology — Fix the topology.yml directory path bug in SR Linux
create_srl_links — Inject inter-node veth pairs over SSH

Step 3 — Push Configuration¶

push_node_config pushes SR Linux CLI config to a specific node:

push_node_config(
    lab_name: str,    # e.g. "r1-r4-ebgp-direct"
    node: str,        # e.g. "r1", "r4"
    config: str       # SR Linux CLI config block
)
# Returns: {"status": "ok", "committed": true}

The ContainerLab server is remote at 192.168.100.12. The tool uses docker exec via SSH — not local.

Step 4 — Verify¶

exec_on_node runs verification commands on the node:

exec_on_node(
    lab_name: str,
    node: str,
    command: str    # e.g. "show network-instance default protocols bgp neighbor"
)

SRL Workarounds (C-NE-30)¶

Nokia SR Linux has two known ContainerLab deployment quirks that deploy_lab handles automatically:

topology.yml Directory Bug¶

After ContainerLab starts, SR Linux nodes look for their startup config in a path constructed from the topology filename. The fix_srl_topology step corrects the directory reference so SR Linux finds its config.

Veth Pair Injection¶

ContainerLab's inter-node links require manual veth pair creation for SR Linux nodes. The create_srl_links step:

SSHs to the ContainerLab server
Identifies all inter-node links from the topology YAML
Creates veth pairs between SR Linux container namespaces
Moves interfaces into place

Example¶

olav --agent ops-lab "Deploy the R1-R4 topology from the latest snapshot and verify eBGP peering"

The Lab Agent:

Calls run_python_simulation to generate 4-node eBGP topology YAML
Calls deploy_lab — deploys topology, fixes SRL bug, injects veths
Calls push_node_config for each node with eBGP config
Calls exec_on_node on each node: show network-instance default protocols bgp neighbor
Reports convergence status: session state, established count, received prefixes