Skip to content

Ansible Collection For SR Linux#

Ansible collection for SR Linux is identified with nokia.srlinux fully qualified collection name and contains the plugins and modules to interface with SR Linux devices.

Collection name nokia.srlinux
Galaxy URL nokia/srlinux
Github repository nokia/srlinux-ansible-collection
SR Linux version >=23.3.11
Python version >=3.6

Modules contained within this collection fully conform to the idempotence principles of Ansible, as well as provide first-class support for diff and check functionality2.


Besides examples provided for each module of this collection, checkout Ansible with SR Linux tutorial to see how to use this collection in practice.


Nokia SR Linux collection provides the following modules that work via HttpApi connection plugin and therefore rely on SR Linux's JSON-RPC server:

Architecturally the modules provide a generic way to retrieve data from and configure SR Linux devices in a model-driven way3. Because SR Linux is a fully-modelled NOS, users should leverage the YANG Browser to navigate the datastores and understand the data model.

Quick examples of how to use the modules. For more information on each module options and return values, please refer to the module's documentation page.

Retrieve configuration and state from SR Linux devices.

- name: Get system information
hosts: clab
gather_facts: false
  - name: Get /system/information container
        - path: /system/information
            datastore: state

Configure SR Linux devices.

- name: Set leaves
hosts: clab
gather_facts: false
  - name: Set system information with values
        - path: /system/information
            location: Some location
            contact: Some contact

Execute CLI commands on SR Linux devices.

- name: Execute "show version" CLI command
  hosts: clab
  gather_facts: false
    - name: Execute "show version" CLI command
          - show version

Validate intended configuration.

- name: Validate
  hosts: clab
  gather_facts: false
    - name: Validate a valid change set
          - path: /system/information
              location: Some location
              contact: Some contact


The recommended way to install galaxy collections is via the ansible-galaxy CLI command that ships with the ansible installation.

ansible-galaxy collection install nokia.srlinux
ansible-galaxy collection install nokia.srlinux:0.1.0 #(1)!
  1. Available version are listed in collection's home page.

Collection is installed at the collections path. Default location is ~/.ansible/collections/ansible_collections/nokia/slinux.

SR Linux configuration#

The factory configuration that SR Linux ships with doesn't have JSON-RPC interface enabled. In order to use the modules of this collection, users should enable and configure the JSON-RPC server.


Ansible supports a number of connection modes to establish connectivity with devices over multiple connection protocols. SSH, HTTP and Local connections are likely the most popular one.

The modules in nokia.srlinux collection interface with SR Linux devices over its JSON-RPC interface, and thus leverage HttpApi connection plugin of Ansible's netcommon collection.

To instruct Ansible to use ansible.netcommon.httpapi connection plugin, users should set the ansible_connection variable to ansible.netcommon.httpapi.

There are many ways to set this variable, though most common one is to set in the inventory file:

clab-ansible-srl  ansible_connection=ansible.netcommon.httpapi ;(1)!
  1. Other variables are omitted


With ansible_network_os variables users select which Network OS the target host runs. For Nokia SR Linux this variable should be set to nokia.srlinux.srlinux value.

Most commonly, this variable is set in the inventory file:

clab-ansible-srl  ansible_network_os=nokia.srlinux.srlinux ;(1)!
  1. Other variables are omitted


Basic HTTP authentication is used by the modules of this collection. Credentials are provided by the common ansible_user and ansible_password variables.


SR Linux JSON-RPC server which the modules of this connection connect to can operate in two modes:

  1. Insecure HTTP mode
    No TLS certificates required, connection is not encrypted
  2. Secure HTTPS mode
    Requires TLS certificate to be generated and configured.

To instruct Ansible to connect to SR Linux device over https protocol users should set the ansible_httpapi_use_ssl variable to true. Again, this can be done on different levels, but most often it is part of the inventory file.

When set ansible_httpapi_use_ssl is set to true, Ansible will try to establish the connection over https using 443 port.

Certificate validation#

By default, when operating over https protocol, Ansible will try to validate the remote host's certificate. To disable certificate verification, set ansible_httpapi_validate_certs to false.

TLS 1.3 support and cipher suites#

In the recent Python versions (>=3.10) default security settings for TLS have been hardened. More specifically the cipher suites have been restricted to the ones that are considered secure.

SR Linux plans to implement TLS 1.3 support in release 23.7, and thus for the time being, users should explicitly set the ansible_httpapi_ciphers variable to the cipher suite that is supported, for example ECDHE-RSA-AES256-SHA.

Example hosts file#

With the above configuration options in mind, the following hosts file demonstrates their usage to connect to the SR Linux device:

clab-ansible-srl ansible_connection=ansible.netcommon.httpapi ansible_user=admin ansible_password=NokiaSrl1! ansible_network_os=nokia.srlinux.srlinux ansible_httpapi_ciphers=ECDHE-RSA-AES256-SHA


To demonstrate the usage of the modules in this collection, we will use a very simple containerlab topology to deploy a single SR Linux node:

name: ansible

      kind: srl

Save the file as ansible.clab.yml and deploy the lab with containerlab deploy -t ansible.clab.yml.

Create the hosts file as shown in the previous section and you're ready to tryout the modules of this collection.

  1. nokia.srlinux collection requires SR Linux 23.3.1 or later. 

  2. See config module for details. 

  3. The modules purposefully don't follow network resource modules pattern, as we wanted to provide a generic way to access the whole configuration and state datastores of the device.