You are currently viewing Containerlab – Helpful Guide To Getting Started – Part 1

Containerlab – Helpful Guide To Getting Started – Part 1

Want to know more about Containerlab?

Containerlab is free software provided by Nokia – yep free, gratis, no licensing, no charge. Containerlab operates as a container-based system, running various routers and OSes. A single lab links these together. This Beginners Guide to Containerlab will provide simplified instructions for the first install. Furthermore, a tutorial on how to get a lab up and running. Finally, an overview of ContainerLab from a network testing perspective.


Containerlab is not a graphical UI like Eve-NG or GNS3 but runs from the command line. The topology is defined using a simple yaml file. This includes both the nodes required and the connections between them.

By default, it uses Docker as the container system. It can, however, use others, such as Podman (some are under Beta testing). Everything below is using Docker.

Each OS type is referred to as a kind. This is then used to define its treatment by the Containerlab.

Nokia has a great set of pages dedicated to the use of Containerlab and has provided many sample labs. All their info is here:



  • Docker installed
  • Sudo privileges
  • Images for the devices – note supports container-based images, plus qcow2 and vmdk – but these are added in different ways.
  • This is tested below on Ubuntu 20.04 – but supported on linux based OSs


For ease, install the latest version of Containerlab, using the command listed below. For other versions, check out the Containerlab page

# download and install the latest release (may require sudo)
bash -c "$(curl -sL <>)"


To upgrade simply perform:

containerlab version upgrade

Files Required

As well as the router images, you will need a few supporting files to aid the creation a new lab within Containerlab.

  • The topology file – Defines the lab and the connections, taking the form of a yaml file.
  • Config files – if needed per device – these can be cli or startup configs. Here, we will use empty configs, hence the need for the yaml file for topology only.


The kind tells the Containerlab how to run the image. Here, we see similarities to the os parameter in the Cisco Genie testbed yaml file.

The following image types are supported. Yet, each type needs some slightly different treatment:

  • Qcow2 instances
  • VM machines
  • Containers

The VM (vmdk) and qcow2 machines need an addon – vrnetlab – to be able to run.

Note: Generally, the kind name will state if the image relies on vrnetlab or not. If it does, it will begin with vr.


As above, VRNetlab is needed to run machines that are non-containerised already. VRNetlab is easily installed.

Note: VRNetlab should be compatible with the version of Containerlab that is running.  VRNetlab is used to build a container image from the VM image which docker is then able to run.

git clone <> && cd vrnetlab

Adding Images

Images are added differently, depending on if:

  • They are containers
  • They rely on vrnetlab

Adding Container Images

Container images can be directly imported to docker – they can and should remain as tgz files:

docker import /path/to/exampleimage.tgz

Check that the image is within docker:

kieran@automan:/etc/containerlab$ sudo docker images
[sudo] password for kieran: 
REPOSITORY                        TAG        IMAGE ID       CREATED        SIZE
ceosimage                         4.21.14M   a8e561ccc101   4 days ago     1.57GB
vrnetlab/vr-veos                  4.27.2F    546204322cd8   4 days ago     932MB
vrnetlab/vr-sros                  12.0.R6    da0661b7e3d5   2 weeks ago    650MB
ubuntu                            20.04      54c9d81cbb44   3 weeks ago    72.8MB             latest     fa99bf16fe53   3 weeks ago    1.3GB
hello-world                       latest     feb5d9fea6a5   5 months ago   13.3kB   latest     ee228f411287   6 months ago   270MB
cmattoon/guestfish                latest     36976c7fd73b   3 years ago    937MB

Certain images – such as srlinux can be pulled automatically if needed.  Add the kind to the topology file and Containerlab will automatically pull the file when the topology is deployed.

Adding VM Images

Each image will need to be copied into the directory:

/etc/containerlab/vrnetlab/<image type>

Within that folder will be an OS specific readme file. This will define how to make the image that vrnetlab can use.

Then, import the image into docker as per the container images:

docker import /etc/containerlab/vrnetlab/<OS Type>/<imagename>

Topology File

The topology file or topo file is a simple yaml file. It defines each node and any connections between nodes.

A node is an individual instance of a kind – i.e. the kind could be SROS, and the nodes could be R1, R2, etc.

The image name used in the topo file must match an image listed with the command:

docker images

If not, modify the topology yaml so it matches an exact image – this is important.

The type is a specific variant of the OS. Review this in the Readme file under each folder.

The links refer to each interface and are unique to the device type. To understand how to define the links per device type, refer to each device page and it will show the list of interfaces:

The simple topology file below will build two nodes: one SRLinux and one Nokia SROS. Now, a pair of links between them exists.

name: vr01

      kind: srl
      kind: vr-sros
      image: vr-sros:20.10.R1
      type: sr-1
      license: license-sros20.txt

    - endpoints: ["srl:e1-1", "sros:eth1"]
    - endpoints: ["srl:e1-2", "sros:eth2"]

Starting and Stopping Labs

Use the containerlab command (with sudo) to start and stop labs.

sudo containerlab deploy --topo <filename.yaml>

and to tear down the lab again:

sudo containerlab destroy --topo <filename.yaml>

Note: If you are starting a brand new lab based on a topology file, the configs created will be new. If you are deploying a lab that has been previously deployed, it will try and load the previous configs.

If you do not want this and want to start fresh – use the –reconfigure flag when you run the deploy command.

Once the lab is started, you will get a status output from the deploy command:

kieran@automan:~$ sudo containerlab deploy --topo /etc/containerlab/lab-with-mods/srlceos01/srlceos01.clab.yml 
INFO[0000] Containerlab v0.23.0 started                 
INFO[0000] Parsing & checking topology file: srlceos01.clab.yml 
INFO[0000] Creating lab directory: /home/kieran/clab-srlceos01 
INFO[0000] Creating docker network: Name='clab', IPv4Subnet='', IPv6Subnet='2001:172:20:20::/64', MTU='1500' 
INFO[0000] Creating container: ceos                     
INFO[0000] Creating container: srl                      
INFO[0001] Creating virtual wire: srl:e1-1 <--> ceos:eth1 
INFO[0001] Running postdeploy actions for Arista cEOS 'ceos' node 
INFO[0001] Running postdeploy actions for Nokia SR Linux 'srl' node 
ERRO[0058] failed to run postdeploy task for node ceos: failed CLI configuration 
INFO[0058] Adding containerlab host entries to /etc/hosts file 
INFO[0058] ? New containerlab version 0.25.1 is available! Release notes:
Run 'containerlab version upgrade' to upgrade or go check other installation options at 
| # |        Name         | Container ID |         Image         | Kind |  State  |  IPv4 Address  |     IPv6 Address     |
| 1 | clab-srlceos01-ceos | 677d6b190d39 | ceosimage:4.21.14M    | ceos | running | | 2001:172:20:20::2/64 |
| 2 | clab-srlceos01-srl  | e10c3b5f3429 | | srl  | running | | 2001:172:20:20::3/64 |

Connecting to Labs

When a lab is up and running, each node will be given a management address that is using the Docker network. These can be seen following deployment, or can be checked at any time using the following:

kieran@automan:~$ sudo containerlab inspect --all
| # |                             Topo Path                             | Lab Name  |        Name         | Container ID |         Image         |  Kind  |  State  |  IPv4 Address  |     IPv6 Address     |
| 1 | ../../etc/containerlab/lab-with-mods/srl02/srl02.clab.yml         | srl02     | clab-srl02-srl1     | 616e356bfb98 | | srl    | exited  | N/A            | N/A                  |
| 2 |                                                                   |           | clab-srl02-srl2     | 5891c92793ad | | srl    | exited  | N/A            | N/A                  |
| 3 | ../../etc/containerlab/lab-with-mods/srlceos01/srlceos01.clab.yml | srlceos01 | clab-srlceos01-ceos | 677d6b190d39 | ceosimage:4.21.14M    | ceos   | running | | 2001:172:20:20::2/64 |
| 4 |                                                                   |           | clab-srlceos01-srl  | e10c3b5f3429 | | srl    | running | | 2001:172:20:20::3/64 |
| 5 | ../../etc/containerlab/lab-with-mods/vr03/vr03.clab.yml           | vr03      | clab-vr03-srl       | c720f9f81811 | | srl    | exited  | | 2001:172:20:20::3/64 |
| 6 |                                                                   |           | clab-vr03-xrv       | ca5673f48f01 | vrnetlab/vr-xrv:5.1.3 | vr-xrv | exited  | | 2001:172:20:20::2/64 |

These nodes are also added to the host machine’s /etc/hosts file. Each router can then directly access via SSH.


Do you want a satisfying diagram of your networking topology? Containerlab can do this for you using the graph function.

Containerlab Diagram (graph)
Containerlab Diagram

There are a few ways to do this, the simplest way is:

containerlab graph -t <filename of topology file>

This will then start an HTML server with a URL that you can go to. Adjust the drawing as needed. You can move the icons around, pick different layouts etc.

For further options for the graphing function see:


I hope this has given you a good initial start guide for Containerlab. My thoughts on Containerlab are that it’s a great tool to get labs up and running rapidly. Also, it’s available for direct SSH access. Unfortunately, it doesn’t provide a satisfying graphical UI, like GNS3 or Eve-NG. Yet, is it even aiming for this? It is ideal for creating a lab that is a blank canvas or for creating one with config files time and time again.

Connecting links must be added via the topology file unlike GNS3 or Eve-NG (Pro version). So, you need to know the topology of the lab before starting.

Containerlab is incredibly useful for testing both automation and network deployments. I am sure it will be heavily developed over the coming months. It’s especially effective when using container images.

I aim to make further postings re: Containerlab when I have spent more time using it.

Comment below on any issues or your points of interest using Containerlab. Or if you are looking for further information, please contact me here.

Share this article...

Leave a Reply