Skip to content

Release 0.50#

2024-01-29 · Full Changelog


Containerlab now natively supports kind clusters as part of its topology by introducing a new kind k8s-kind.

Since more and more applications (including network management systems and network functions) are being deployed in the k8s clusters, it is important to be able to test the network connectivity between the k8s workloads and the underlay network.

Kind is a tool for running local Kubernetes clusters using Docker container “nodes”. By integrating kind clusters via a new kind k8s-kind with containerlab, it is possible to spin-up kind clusters as part of the containerlab topology.

This deployment model unlocks the possibility to integrate network underlay created by containerlab with the workloads running in the kind clusters in a single YAML file. The integration between kind clusters and containerlab topology makes it easy to deploy and interconnect k8s clusters and the underlay network.

Ansible inventory improvements#

We've shipped containerlab with the automatic Ansible inventory generation for quite a while now. It is a very convenient way to get the inventory file for the Ansible playbooks that can be used to configure the nodes in the topology.

Now we've improved the inventory generation by adding some additional Ansible variables for a few node kinds. If you use nokia_srlinux or nokia_sros kinds you will find the following variables in the inventory file:

  • ansible_user - set to the default username of the node
  • ansible_password - set to the default password of the node
  • ansible_connection - set to network_cli for the SR OS nodes and to httpapi for the SR Linux nodes
  • ansible_network_os - set to nokia.sros.sros for the SR OS nodes and to nokia.srlinux.srlinux for the SR Linux nodes

With these variables set you can start using Ansible right away without setting these variables elsewhere.

If you need the same functionality for other node kinds, please raise a PR or an issue.

Using nftables API#

With #1362 containerlab now starts using nftables API backend when installing iptables rules to allow external access for the nodes.

NFtables API is a new way to manage nftables/iptables rules and has been part of the kernel for quite a while. Still, some old kernels known to be used in Centos/RHEL distros up to and including version 7 might not have the nftables API available.

In that case, containerlab will fail to setup external access rules and users would have to do it manually.

SANs move to Certificate level#


This is a non backwards compatible change!

We offered the users to set additional Subject Alternative Names (SANs) for the generated certificates via the .san node property. But then we introduced the .certificate node property to tune certificate parameters for a given node or a kind.

Now we are moving the SANs to the certificate level to keep things under one roof.


  • TLS certificates that containerlab provides for the nodes now also include KeyEncipherment usage role #1822
  • xrv9k default mem and cpu values have been increased to 16 GB and 2 vCPUs respectively #1806
  • SR Linux admin user's rc files are now owned by admin user #1832
  • Updated wireshark docs #1842
  • Config apply timeout for the SR OS nodes has been increased to 15 minutes #1835