Skip to main content

Containerlab

This page covers the optional containerlab integration: what runs, which PEs are substituted, how to deploy, and known limitations.

Overview​

The containerlab artifact (clab-mpls-topology) is generated from Infrahub data by the clab_topology transform and renders a valid containerlab YAML topology. It wires up the lab-deployable PE nodes plus the L3VPN CE nodes for end-to-end testing. The backbone links are data-driven — derived from the shared /31 addressing rather than fixed in the template — so the lab tracks whatever backbone the active dataset defines.

Which PEs are deployable depends on the dataset:

  • financial (default) — all 8 PEs are Arista cEOS, so all 8 boot in the lab and all 12 backbone links render.
  • isp — only the Arista and Nokia PEs have a lab-runnable image, so 2 PE nodes boot with the single backbone link between them.

The topology is written to lab/mpls-topology.clab.yml by invoke lab.deploy before containerlab brings it up.

Node map​

A PE is lab-deployable only when its platform carries a containerlab_os image. Today that means two vendors:

VendorPlatformContainerlab imageNotes
Arista EOSarista_eosceos:latestFull configuration push via invoke lab.push-arista
Nokia SR OSnokia_srosSR Linux (ghcr.io/nokia/srlinux)SR Linux used in place of SR OS (see below)
Cisco IOS-XRcisco_iosxr—No lab image — omitted from the topology
Juniper Junosjuniper_junos—No lab image — omitted from the topology

Which PEs that yields depends on the active dataset:

  • financial (default) — all 8 PEs (pe-01…pe-08) are Arista cEOS, so all 8 boot in the lab and all 12 backbone links render.
  • isp — only pe-lon-arista (cEOS) and pe-par-nokia (SR Linux) are deployable; pe-fra-cisco and pe-ams-juniper are omitted.

CE nodes run a generic Linux image (ghcr.io/hellt/network-multitool) and simulate customer CPE with a loopback address.

SR OS → SR Linux substitution​

This applies only when the active backbone includes a Nokia PE — i.e. the isp dataset. The default financial backbone is all-Arista, so no substitution happens there.

Nokia's containerlab-friendly image is SR Linux, not SR OS. SR OS is available only with a paid Nokia licence and is not suitable for a public demo. The demo uses SR Linux as a stand-in for the Nokia PE. The Infrahub data model remains nokia_sros for schema consistency; the containerlab artifact swaps in the SR Linux image automatically.

The SR Linux node boots with the generated Nokia SR OS configuration loaded as a startup configuration, but SR Linux does not parse SR OS CLI syntax. Configuration push to the Nokia PE is therefore not available in v1 (see Known gaps).

Prerequisites​

  • containerlab >= 0.50
  • Docker with access to pull:
  • A running Infrahub instance with bootstrap data loaded (invoke init)

Deploy​

# Fetch the clab artifact from Infrahub and write lab/mpls-topology.clab.yml,
# then call containerlab deploy.
uv run invoke lab.deploy

Expected output (default financial dataset — 8 Arista cEOS PEs plus the four trading-floor-vpn CE nodes):

[INFO] Fetching clab-mpls-topology artifact from Infrahub...
[INFO] Writing lab/mpls-topology.clab.yml
[INFO] Running: containerlab deploy -t lab/mpls-topology.clab.yml
...
+----+---------------------------------+-----------+---------------------------------+
| #  | Name                            | Kind      | Image                           |
+----+---------------------------------+-----------+---------------------------------+
| 1  | pe-01                           | ceos      | ceos:latest                     |
| 2  | pe-02                           | ceos      | ceos:latest                     |
| 3  | pe-03                           | ceos      | ceos:latest                     |
| 4  | pe-04                           | ceos      | ceos:latest                     |
| 5  | pe-05                           | ceos      | ceos:latest                     |
| 6  | pe-06                           | ceos      | ceos:latest                     |
| 7  | pe-07                           | ceos      | ceos:latest                     |
| 8  | pe-08                           | ceos      | ceos:latest                     |
| 9  | ce-trading-floor-vpn-pe-01      | linux     | ghcr.io/hellt/network-multitool |
| 10 | ce-trading-floor-vpn-pe-02      | linux     | ghcr.io/hellt/network-multitool |
| 11 | ce-trading-floor-vpn-pe-03      | linux     | ghcr.io/hellt/network-multitool |
| 12 | ce-trading-floor-vpn-pe-04      | linux     | ghcr.io/hellt/network-multitool |
+----+---------------------------------+-----------+---------------------------------+

On the isp dataset the same command brings up just pe-lon-arista (Arista cEOS) and pe-par-nokia-lab (Nokia SR Linux), plus its CE nodes.

Push Arista configuration​

After the lab is up, push the Arista EOS configuration artifact from Infrahub:

uv run invoke lab.push-arista

This fetches the Arista EOS configuration artifact(s) from Infrahub via the SDK and applies them over the containerlab management network using pyeapi / SSH. On the default financial backbone every PE is Arista (pe-01…pe-08); on the isp dataset it is the single pe-lon-arista node.

The command shows a diff of what changed. Verify with (financial default — substitute pe-lon-arista on the isp dataset):

containerlab exec -t lab/mpls-topology.clab.yml --label clab-node-name=pe-01 \
  --cmd "show bgp vpn-ipv4 summary"

Destroy​

uv run invoke lab.destroy

This calls containerlab destroy and removes the generated topology file.

Lab status​

uv run invoke lab.status

Shows container health without modifying anything.

Login credentials​

containerlab registers each node in its embedded DNS as clab-<lab-name>-<node-name>. For the bundled MPLS backbone the lab name is mpls-backbone-1, so on the default financial dataset the Arista PEs are at clab-mpls-backbone-1-pe-01 … clab-mpls-backbone-1-pe-08. On the isp dataset the Arista PE is clab-mpls-backbone-1-pe-lon-arista and the Nokia PE is clab-mpls-backbone-1-pe-par-nokia.

NodeImageUserPasswordNotes
Arista PE (pe-01…pe-08 on financial, pe-lon-arista on isp)Arista cEOSadminadminSet by our startup-configuration, demo-only
pe-par-nokia (CLI) — isp onlyNokia SR LinuxadminNokiaSrl1!SR Linux 22.11+ vendor default
pe-par-nokia (shell) — isp onlyNokia SR LinuxlinuxadminNokiaSrl1!Shell access, same default
ce-* (netshoot)nicolaka/netshootroot(none)Plain Linux containers

To reach the CLIs:

# Arista — via SSH or docker exec (financial default; use pe-lon-arista on isp)
ssh admin@clab-mpls-backbone-1-pe-01
docker exec -it clab-mpls-backbone-1-pe-01 Cli

# Nokia SR Linux (isp dataset only)
ssh admin@clab-mpls-backbone-1-pe-par-nokia
docker exec -it clab-mpls-backbone-1-pe-par-nokia sr_cli

# CE Linux node (financial default)
docker exec -it clab-mpls-backbone-1-ce-trading-floor-vpn-pe-01 bash

The cEOS password (admin) is set by the startup-configuration we render — specifically the username admin privilege 15 role network-admin secret 0 admin line in templates/pe_arista_eos.j2. It's demo-only; if you ever publish from this template to real Arista hardware, swap the secret or gate the line behind a flag.

The Nokia password is the SR Linux 22.11+ default. Older SR Linux releases used admin as the password — adjust if you've pinned a different image tag in templates/clab_topology.j2.

Known gaps​

GapDetails
Nokia SR Linux configuration pushSR Linux uses a different CLI/API from SR OS, and the public SR Linux 23.10 image lacks several constructs SR OS supports (LDP, l3vpn-ipv4-unicast afi-safi, bgp-vpn under network-instance). The dedicated pe-nokia-srlinux artifact intentionally renders a lab-minimum configuration — hostname + interfaces + ISIS underlay only. BGP and per-VPN ip-vrf signalling are skipped on the SRL lab node. The production-quality configuration lives in the pe-nokia-sros artifact (real SR OS syntax) and is meant for a real Nokia box.
Cisco / Juniper PEsIOS-XR and Junos container images require vendor licences; these PEs are absent from the v1 lab topology.
CE routingCE nodes have loopbacks but no BGP daemon configured. Confirming end-to-end L3VPN reachability requires manual CE configuration.

Image pull failures​

If containerlab fails with Error response from daemon: pull access denied:

  1. SR Linux (ghcr.io/nokia/srlinux) — requires a GitHub login: docker login ghcr.io -u <github-user> -p <PAT>

  2. cEOS — the image is not on any public registry. Download the .tar.xz from https://www.arista.com/en/support/software-download and import it:

    docker import cEOS-lab-4.30.0F.tar.xz ceos:latest

  3. network-multitool (ghcr.io/hellt/network-multitool) — public image; if it fails, check Docker Hub rate limits or mirror via a local registry.