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:

Vendor	Platform	Containerlab image	Notes
Arista EOS	`arista_eos`	`ceos:latest`	Full configuration push via `invoke lab.push-arista`
Nokia SR OS	`nokia_sros`	SR Linux (`ghcr.io/nokia/srlinux`)	SR Linux used in place of SR OS (see below)
Cisco IOS-XR	`cisco_iosxr`	—	No lab image — omitted from the topology
Juniper Junos	`juniper_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:
- ceos:latest (requires an Arista account and local image import — see https://containerlab.dev/manual/kinds/ceos/)
- ghcr.io/nokia/srlinux (public)
- ghcr.io/hellt/network-multitool (public)
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.

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.

Node	Image	User	Password	Notes
Arista PE (`pe-01`…`pe-08` on financial, `pe-lon-arista` on isp)	Arista cEOS	`admin`	`admin`	Set by our startup-configuration, demo-only
`pe-par-nokia` (CLI) — isp only	Nokia SR Linux	`admin`	`NokiaSrl1!`	SR Linux 22.11+ vendor default
`pe-par-nokia` (shell) — isp only	Nokia SR Linux	`linuxadmin`	`NokiaSrl1!`	Shell access, same default
`ce-*` (netshoot)	nicolaka/netshoot	`root`	(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

Gap	Details
Nokia SR Linux configuration push	SR 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 PEs	IOS-XR and Junos container images require vendor licences; these PEs are absent from the v1 lab topology.
CE routing	CE 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:

SR Linux (ghcr.io/nokia/srlinux) — requires a GitHub login: docker login ghcr.io -u <github-user> -p <PAT>
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
```
network-multitool (ghcr.io/hellt/network-multitool) — public image; if it fails, check Docker Hub rate limits or mirror via a local registry.

Overview​

Node map​

SR OS → SR Linux substitution​

Prerequisites​

Deploy​

Push Arista configuration​

Destroy​

Lab status​

Login credentials​

Known gaps​

Image pull failures​