Skip to content

Release 0.41#

2023-05-11 ยท Full Changelog

Parameters renaming#


To unify the style of the topology definition file parameters, the following keys have been renamed:

  • mgmt_ipv4 -> mgmt-ipv4
  • mgmt_ipv6 -> mgmt-ipv6
  • ipv4_subnet -> ipv4-subnet
  • ipv6_subnet -> ipv6-subnet

The old keys are deprecated and containerlab will emit a warning if they are used in the topology definition file. To quickly adapt the topology definition file to the new format use the following script that recursively replaces the old keys with the new ones for all yaml files in the current working directory:

find . -name '*.yaml' -o -name '*.yml' | while read file; do

    # Replace mgmt_ip
    sed -i 's/mgmt_ipv4:/mgmt-ipv4:/g' "$file"
    sed -i 's/mgmt_ipv6:/mgmt-ipv6:/g' "$file"

    # Replace ip_subnet
    sed -i 's/ipv4_subnet:/ipv4-subnet:/g' "$file"
    sed -i 's/ipv6_subnet:/ipv6-subnet:/g' "$file"


Juniper vSRX support#

In #1352 @Exhar added support for vSRX using vrnetlab. See for implementation details on the vrnetlab side. The new node kind is vr-juniper_vsrx.

In #1345 we added support for IPv4/6 SANs for SR Linux nodes. With this addition, the certificate will contain IPv4/6 addresses assigned by the container runtime as SANs, so TLS connections can be established using these addresses.

Management IP range for Docker runtime#

With #1365 @steiler added support for a new property of a management network - ip-range - that allows to specify a range of IP addresses that will be used by the Docker runtime to assign IP addresses from the specified subnet.

This is particularly useful when you want to restrict docker from using a sub-block of the subnet that is used by the management network when it is, for example, used by another orchestrator.

Automatic load of iptables modules#

With #1363 merged, we hopefully crossed out one of the most annoying issues with containerlab - the need to manually load ip_tables and ip6_tables kernel modules on the host. These modules enable containerlab to provide external connectivity for the nodes and are crucial for VM-based nodes' datapath operation.

Now containerlab will try to load these modules automatically if they are not loaded yet.

Environment variables in topology definition file#

A hidden feature of containerlab is the ability to use environment variables in the topology definition file. This feature is helpful when you want to parametrize the topology file based on the environment where it is deployed. For example, you can use it to specify the image URI for the nodes, or a particular path to the config files.

Now we enhanced the support for environment variables by adding bash-style variable expansion support. This means that you can use the following syntax to expand the environment variables in the topology definition file:

name: linux

      kind: linux
      image: alpine:${ALPINE_VERSION:=3}

Where the syntax means that if the ALPINE_VERSION environment variable is not set, the default value of 3 will be used. With that, you can now use the same topology definition file for different environments by setting the environment variables accordingly.


  • Fixed regression in external bridge support in #1361
  • Fixed Ansible inventory generation to honor --no-host-var flag for user groups #1369
  • We removed dependency on cloudflare ssl package in #1308 where @steiler used Go standard library to generate CA and node's certificates and keys.



We admit that we were too harsh with the removal of the old keys in v0.41.0. We decided to bring them back and deprecate them instead. This will allow users to migrate to the new keys at their own pace. #1391

The deprecated fields will stay for a few months and a log message will be printed when they are used.

  • Fixed public keys population for password-less SSH access for SR Linux nodes #1384
  • Added support for extracting public keys from SSH agent #1388
  • Added json_schema types for SR OS #1387


  • fix an issue where deprecated mgmt_ipv6 overwrites mgmt_ipv4 value #1397