Skip to content

Get Started

SR Linux packs a lot of unique features that the IP and data center networking teams can leverage. Some of the features are truly new to the networking domain. The goal of this portal is to introduce SR Linux to visitors through interactive tutorials centered around SR Linux services and capabilities.

We believe that learning by doing yields the best results. With that in mind we made SR Linux container image available to everybody without any registration or licensing requirements 🥳

The public SR Linux container image when powered by containerlab allows us to create easily deployable labs that everyone can launch at their convenience. All that to let you not only read about the features we offer, but to try them live!

SR Linux container image#

A single container image that hosts management, control and data plane functions is all you need to get started.

Getting the image#

To make our SR Linux image available to everyone, we pushed it to a publicly accessible GitHub container registry. This means that you can pull SR Linux container image exactly the same way as you would pull any other image:

docker pull

When image is referenced without a tag, the latest container image version will be pulled. To obtain a specific version of a containerized SR Linux, refer to the list of tags the nokia/srlinux image has and change the docker pull command accordingly.

Running SR Linux#

When the image is pulled to a local image store, you can start exploring SR Linux by either running a full-fledged lab topology, or by starting a single container to explore SR Linux CLI and its management interfaces.

A system on which you can run SR Linux containers should conform to the following requirements:

  1. Linux OS with a kernel v4.10+1.
  2. Docker container runtime.
  3. At least 2 vCPU and 4GB RAM.
  4. A user with administrative privileges.

Let's explore the different ways you can launch SR Linux container.

Docker CLI#

docker CLI offers a quick way to run a standalone SR Linux container:

sudo docker run -t -d --rm --privileged \
  -u 0:0 \
  -v srl23-7-1.json:/etc/opt/srlinux/config.json \ #(1)!
  --name srlinux \
  sudo bash /opt/srlinux/bin/sr_linux
  1. By default container starts with a factory config, if you want to start with a custom config, mount it to /etc/opt/srlinux/config.json path.
    In this example, config created by containerlab is mounted to the container.

The above command will start the container named srlinux emulating D3L4 hardware on the host system with a single management interface attached to the default docker network.

To connect to the CLI of the container you can either use docker exec -it srlinux sr_cli or SSH to the container over the network:

# default password is NokiaSrl1!
ssh admin@$(docker inspect -f '{{.NetworkSettings.IPAddress}}' srlinux)

Using docker CLI is a viable approach when all you need is to run a standalone container to explore SR Linux CLI or to use its management interfaces. However, it is not particularly suitable to run multiple SR Linux containers with links between them, as this requires some extra work.

For multi-node SR Linux deployments containerlab3 offers a better way.


Containerlab provides a CLI for orchestrating and managing container-based networking labs. It starts the containers, builds a virtual wiring between them and manages labs lifecycle.

A quickstart guide is a perfect place to get started with containerlab. For the sake of completeness, let's have a look at the containerlab file that defines a lab with two SR Linux nodes connected back to back together:

# file: srlinux.clab.yml
name: srlinux

      kind: srl
      kind: srl

    - endpoints: ["srl1:e1-1", "srl2:e1-1"]

By copying this file over to your system you can immediately deploy it with containerlab:

containerlab deploy -t srlinux.clab.yml
INFO[0000] Parsing & checking topology file: srlinux.clab.yml 
INFO[0000] Creating lab directory: /root/demo/clab-srlinux 
INFO[0000] Creating container: srl1                     
INFO[0000] Creating container: srl2                     
INFO[0001] Creating virtual wire: srl1:e1-1 <--> srl2:e1-1 
INFO[0001] Writing /etc/hosts file                      
| # |        Name        | Container ID |         Image         | Kind | Group |  State  |  IPv4 Address  |     IPv6 Address     |
| 1 | clab-srlinux-srl1  | 50826b3e3703 | | srl  |       | running | | 2001:172:20:20::2/64 |
| 2 | clab-srlinux-srl2  | 4d4494aba320 | | srl  |       | running | | 2001:172:20:20::4/64 |

Deployment verification#

Regardless of the way you spin up SR Linux container it will be visible in the output of the docker ps command. If the deployment process went well and the container did not exit, a user can see it with docker ps command:

$ docker ps
CONTAINER ID   IMAGE                      COMMAND                  CREATED             STATUS             PORTS                    NAMES
4d4494aba320      "/tini -- fixuid -q …"   32 minutes ago      Up 32 minutes                               clab-learn-01-srl2

The logs of the running container can be displayed with docker logs <container-name>.

In case of the misconfiguration or runtime errors, container may exit abruptly. In that case it won't appear in the docker ps output as this command only shows running containers. Containers which are in the exited status will be part of the docker ps -a output.
In case your container exits abruptly, check the logs as they typically reveal the cause of termination.


This portal does not substitute but augments the official SR Linux documentation. You can find official docs using one of the following links:

  1. SR Linux documentation collection -
  2. Short and memorizable URLs with the release version being part of the URL
    1. for the main documentation pages of SR Linux 22.11 release.
    2. for a direct link to Release Notes.
  3. Network Infrastructure documentation collection -

Connecting to SR Linux#

When SR Linux container is up and running, users can connect to it over different interfaces.


One of the ways to manage SR Linux is via its advanced and extensible Command Line Interface.

To invoke the CLI application inside the SR Linux container get container name/ID first, and then execute the sr_cli process inside of it:

# get SR Linux container name -> clab-srl01-srl
$ docker ps
CONTAINER ID   IMAGE                             COMMAND                  CREATED          STATUS         PORTS                    NAMES
17a47c58ad59             "/tini -- fixuid -q …"   10 seconds ago   Up 6 seconds                            clab-learn-01-srl1
# start the sr_cli process inside this container to get access to CLI
docker exec -it clab-learn-01-srl1 sr_cli
Using configuration file(s): []
Welcome to the srlinux CLI.
Type 'help' (and press <ENTER>) if you need any help using this.
--{ running }--[  ]--                                                                                                                           

The CLI can also be accessed via an SSH service the SR Linux container runs. Using the default credentials admin:NokiaSrl1! you can connect to the CLI over the network:

# containerlab creates local /etc/hosts entries
# for container names to resolve to their IP
ssh admin@clab-learn-01-srl1

admin@clab-learn-01-srl1's password: 
Using configuration file(s): []
Welcome to the srlinux CLI.
Type 'help' (and press <ENTER>) if you need any help using this.
--{ running }--[  ]--                                                                                                                           


SR Linux containers deployed with containerlab come up with gNMI interface up and running over port 57400.

Using the gNMI client2 users can explore SR Linux' gNMI interface:

gnmic -a clab-srlinux-srl1 --skip-verify -u admin -p 'NokiaSrl1!' capabilities
gNMI version: 0.7.0
supported models:
  - urn:srl_nokia/aaa:srl_nokia-aaa, Nokia, 2021-03-31
  - urn:srl_nokia/aaa-types:srl_nokia-aaa-types, Nokia, 2019-11-30
  - urn:srl_nokia/acl:srl_nokia-acl, Nokia, 2021-03-31

  1. Centos 7.3+ has a 3.x kernel and won't be able to run SR Linux container images newer than v22.11. 

  2. for example gnmic 

  3. The labs referenced on this site are deployed with containerlab unless stated otherwise 

  4. Prior to SR Linux v23.3 users had to mount a topology file for a container to start.