Skip to content

Release 0.56#

2024-07-09 ยท Full Changelog

Interface aliases#

We know, it has been a long time coming, but thanks to a brilliant contribution done by @vista- in #2124 we now have added support for interface aliases.

What are interface aliases you ask? They are a way to use interface names as you see them in the NOS CLI, rather than the default ethX naming scheme. It is a convenience feature, but, oh boy, how much easier is it to define links when you don't have to keep doing the mental gymnastics of mapping eth0 to Gi0/1 and so on.

Imagine we want to create a lab with four different Kinds: SR Linux, vEOS, CSR1000v and vSRX, cabled like this:

A side B side
SR Linux ethernet-1/1 vEOS Ethernet1/1
vSRX ge-0/0/2 vEOS Ethernet1/2
CSR1000v Gi5 vSRX ge-0/0/5
vEOS Ethernet1/3 CSR1000v Gi3

Using the ethX interface naming convention, the topology would look like this:

links:
  - endpoints: ["srl:e1-1", "vEOS:eth1"]
  - endpoints: ["vSRX:eth3", "vEOS:eth2"]
  - endpoints: ["CSR1000v:eth4", "vSRX:eth6"]
  - endpoints: ["vEOS:eth3", "CSR1000v:eth2"]

Note the four different kinds of offset used here on the four different NOSes!

Using aliased interface names, the topology definition becomes much more straightforward:

links:
  - endpoints: ["srl:ethernet-1/1", "vEOS:Ethernet1/1"]
  - endpoints: ["vSRX:ge-0/0/2", "vEOS:Ethernet1/2"]
  - endpoints: ["CSR1000v:Gi5", "vSRX:ge-0/0/5"]
  - endpoints: ["vEOS:Ethernet1/3", "CSR1000v:Gi3"]

Both topology definitions result in the same lab being deployed, but the latter is easier to write and to understand.

Many Kinds (but not all) support interface aliases and the alias names are provided in the respective kind' documentation.

Containerlab transparently maps from interface aliases to Linux interface names, and there's no additional syntax or configuration needed to specify either an interface alias or a Linux interface name in topologies.

Interface aliases will be also displayed in the generated graph and even in the edgeshark web view.

pic1

pic2

Ostinato support#

We have added support for Ostinato traffic generator in containerlab. You can now define Ostinato nodes in your topology file and use them to generate traffic between your nodes.

See the Ostinato integration page for more details.

SONiC#

We have added support for the following new SONiC kinds:

Multi-arch clab container build#

To support the imminent release of ARM64 friendly Network OSes we fine tuned the release pipeline to make sure the clab container is built for both amd64 and arm64 architectures. #2128

Cisco Catalyst 9000v#

Thanks to our strong community and @kaelemc in particular, we have added support for the Cisco Catalyst 9000v switch. #2133

Miscellaneous#

  • Additions to the Developers Guide done by @pstavirs go about how to contribute to the documentation and how to build the documentation locally. #2109
  • Added more community posts in #2127