Skip to content

Release 0.17#


Environment variables expansion#

A new feature contributed by @GrigoriyMikhalkin allows you to perform environment variables expansion throughout the whole clab topology file.

This allows you to modify topology definition at runtime using the env vars you have defined in your environment. Awesome addition to make clab play nice in CI/CD systems!

Local config takes precedence over startup config#

A major change has been made to the config load order. With this release the following order of configuration load is in place:

  1. config file found in lab directory
  2. startup config set with startup-config setting
  3. generated config from a template that comes within containerlab

The change is with the local config to be preferred over a startup-config. The idea here is simple: when a user deploys a lab from with a startup-config pointing to a certain file the lab boots with this config.

Later, users typically build on top of that startup config some additional use cases. And in the case they save their changes to the startup config the changes will be persisted in a lab directory of this node. Now, if a users destroys a lab and deploys it again, if the file in the lab dir is found, it will be used, and startup-config will be ignored.

If it is needed to make a config file referenced in startup-config to be used, the deploy command should be augmented with reconfigure flag or a new parameter can be used in the topo file - enforce-startup-config.

Arista cEOS persistency improvements#

A big improvement in the way management interface is configured for ceos kinds.

With a new scrapligo feature we were able to configure ceos nodes over docker exec command after the node finishes booting. That allowed us to always ensure that ceos nodes will have management interface addressed with the IP that docker assigned to it, regardless of which IP was already set in startup-config file.

That made it possible to remove a lot of workarounds and restrictions that were in place before.

Mixed mode labs with Static and Dynamic IP addresses#

Containerlab allows users to set static IP address for the node management interface. This is done with mgmt_ipv4/6 setting of a node.

It was possible to set static address for part of the nodes of a lab, in that case some nodes will get a static address, the rest would receive an address as assigned by Docker daemon. The issue that users might see with such labs is that docker assigns dynamically an IP that was set as a static IP for another node.

To overcome this race condition the nodes with Static IP address will now be scheduled first, and the dynamic IP allocated nodes will follow.

Startup delay for nodes#

Nodes can be artificially delayed if they have startup-delay field set to a value greater than zero. This indicates amount in seconds that this node will wait till it will be scheduled for creation by containerlab.

New contributors#

Welcome @GrigoriyMikhalkin and thank you for your contributions to containerlab!