Instant SR Linux Labs#
Containerlab already made it possible to quickly launch labs on demand with just a few commands. You would need to clone a repository with the lab and then call containerlab deploy to start the lab.
Simple enough, but quite often you want to run this simple SR Linux lab to test something quickly using a very basic topology. At times like this it is cumbersome to find and clone the repository and then call deploy command. Can we make it even more simple? Yes, we can!
If we have two steps to start a lab (cloning and calling deploy) we can combine them into one step by using two different approaches:
- provide HTTP(S) URL to the deploy command and let containerlab fetch the clab file and deploy from it
- provide GitHub/GitLab URL to the
deploycommand and let containerlab clone the repo for us and deploy from it - curl the lab definition file from the repository and pipe it to
containerlab deploycommand
These approaches are equally simple, but they have quite distinct powers and limitations. Let's explore them in more detail.
Warning
These features require containerlab v0.48.2 or later.
Using HTTP(S) URL#
Deploying a lab from a remote HTTP(S) URL is the simplest way to get a lab up and running. All you need to do is to provide the URL to the deploy command and containerlab will fetch the file and deploy from it.
When deploying a clab file from a remote URL containerlab will download the clab file to a temporary directory - /tmp/.clab - and then perform a deploy command using the downloaded file. The temporary file will be deleted when the lab is destroyed with the cleanup flag provided.
Your Containerlab lab directory will still get created in the current working directory. While this is the default Containerlab behavior, it might not be quite useful for this particular case since you might want to quickly boot a lab from a dir where you don't want to see extra files popping up.
For this case, leverage CLAB_LABDIR_BASE env var to influence where Containerlab should put the lab directory:
Where exactly is my topology file?
The lab file is downloaded to a temporary location as can be verified with the containerlab inspect --all command:
$ containerlab inspect --all
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| # | Topo Path | Lab Name | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
| 1 | ../../../tmp/.clab/topo-288756812.clab.yml | srl | srl | 6b5cad8a221d | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.2/24 | 2001:172:20:20::2/64 |
+---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
Using HTTP-based lab deployment technique opens up a door to quickly deploy simple SR Linux labs with a single mermorizable command. This is handy when you need to quickly test something on SR Linux or demonstrate a feature to a colleague.
Single node SR Linux lab#
Here is the lab definition file that we used in the above example:
name: srl
# node name will be srl unless overridden by CLAB_PREFIX
prefix: ${CLAB_PREFIX:=""}
topology:
nodes:
srl:
kind: nokia_srlinux
image: ${SRL_IMAGE:=ghcr.io/nokia/srlinux}:${SRL_VERSION:=latest}
type: ${SRL_TYPE:=ixrd3l}
As you can see, it is a simple single-node lab with SR Linux node named srl. This lab is meant for users who just want to quickly test something on a single SR Linux node and doesn't require any networking part to be configured.
The command can even be shortened further to:
Once the lab is deployed you can type in ssh srl and get access to the SR Linux shell. Easy!
Parametrization#
An attentive reader might have noticed that the lab definition file contains some environment variables. They allow to parametrize the lab definition file and change the SR Linux version or the type of the node.
If you deploy the commands as we did a few moments ago, the lab will be deployed with the default parameters:
ghcr.io/nokia/srlinux:latestimage will be usedixrd3ltype will be used- lab prefix is removed
If you wish to change the SR Linux version or the type, you can do so by providing the env vars to the containerlab command:
SRL_VERSION=23.10.1 SRL_TYPE=ixrd2 \
sudo containerlab deploy -c -t srlinux.dev/clab-srl
Since the default value for the lab prefix is an empty string, the node name (as well as container name) will be just srl. This makes it easy to connect to the node with ssh srl command, but if you want to deploy multiple labs with the same topology, you will need to change the prefix to avoid name collisions. Simply set CLAB_PREFIX variable to any value you want.
Two-node SR Linux lab#
In exactly the same spirit as the single-node lab, we thought it would be cool to have two SR Linux nodes connected back-to-back together. This lab can be deployed as:
This lab deploys nodes srl1 and srl2 and provides the same environment variables to parametrize the lab definition file.
Limitations#
The limitations of this approach is that clab file can not have external files used in the lab definition. For example, if you have a lab definition that relies on bind mounting of local files, you will not be able to deploy it from a remote URL. But thankfully we have a way to deploy labs from git repositories 
Using Git URL#
Containerlab added support for GitHub/GitLab URLs provided to the deploy command. The linked documentation article explains how different flavors of git URLs can be used to deploy labs from managed git repositories.
What is important for us here, is that we can now deploy full-blown labs by simply copying URL of the lab repository from the browser. Here is how it works:
Because containerlab will clone the repository, the limitations of the previous approach are not applicable here. Your repository will be cloned in its entirety and therefore you will have access to all the files that are part of the repository. For example, deploying the SR Linux Streaming Telemetry Lab is as simple as:
sudo clab dep -c -t https://github.com/srl-labs/srl-telemetry-lab
Did you know?
For GitHub-hosted repos you can shrink the URL down to just as user/repo, for example:
Using curl#
And then lastly, you can use curl, wget or any other HTTP client to fetch the clab file and pipe it to containerlab deploy command. That way you can provide custom proxies to the HTTP client if required.
For example, deploying the same single-node SR Linux lab with curl can be done as:
Summary#
In this post we showed different ways to quickly deploy a single or two-node SR Linux lab using a simple, memorizable commands. Anywhere you are, you can just type in curl -sL srlinux.dev/clab-srl | containerlab deploy -c -t - and get a lab up and running in a matter of seconds.
We identified which limitations deployment from a remote URL has and how to overcome them by deploying labs from git repositories. Giving the flexibility in options whilst keeping the simplicity of the deployment process is what makes containerlab a great tool for SR Linux labs in particular and networking labs in general.