Skip to content

Operating the lab

Everything you need after the first successful run.

In this section

  •   Make targets

    The complete list — lab lifecycle, environment lifecycle, quality gates, and the targets the two vendored tooling repos contribute. What each one does and when to reach for it.

  •   Images

    The two local-only images this repo builds (neops-lab-frr, neops-lab-bootstrap), the four published images it consumes, and how to swap any of them for a local build.

  •   Adding a device

    The four-step loop: edit the scenario’s topology.json, regenerate, redeploy, commit the regenerated parameter files — because the generator tests will fail until you do.

  •   Troubleshooting

    Indexed by symptom. Most failures here are one of three boot-order races, each with a distinctive error string and a wait that already exists to prevent it.

  •   Kubernetes lab

    The FRR devices as pods in a local KIND cluster, reached by in-cluster DNS. A second flavour of the lab that needs neither containerlab nor the control plane.

The lifecycle at a glance

stateDiagram-v2
    [*] --> Clean
    Clean --> BaseUp: make local-env-init
    BaseUp --> LabUp: make local-lab-up
    LabUp --> Populated: make local-lab-discover
    Populated --> BaseUp: make local-lab-down
    LabUp --> BaseUp: make local-lab-down
    BaseUp --> Clean: make local-env-prune
    Populated --> Populated: make local-lab-discover

local-lab-down destroys the devices and stops the containers but keeps the Elasticsearch and Postgres volumes, so the CMS data survives. local-env-prune is the real reset.

Every target above acts on one scenario, selected with SCENARIO and defaulting to wan-and-fabric. One scenario runs at a time — see Scenarios.