Kinds#
Containerlab launches, wires up and manages container based labs. The steps required to launch a vanilla debian
or centos
container image aren't at all different. On the other hand, Nokia SR Linux launching procedure is nothing like the one for Arista cEOS.
Things like required syscalls, mounted directories, entrypoints and commands to execute are all different for the containerized NOS'es. To let containerlab understand which launching sequence to use, the notion of a kind
was introduced. Essentially kinds
abstract away the need to understand certain setup peculiarities of different NOS'es.
Given the following topology definition file, containerlab is able to know how to launch node1
as an SR Linux container and node2
as a cEOS one because they are associated with the kinds:
name: srlceos01
topology:
nodes:
node1:
kind: srl # node1 is of srl kind
type: ixrd2
image: ghcr.io/nokia/srlinux
node2:
kind: ceos # node2 is of ceos kind
image: ceos:4.25F
links:
- endpoints: ["node1:e1-1", "node2:eth1"]
Containerlab supports a fixed number of kinds. Within each predefined kind we store the necessary information that is used to launch the container successfully. The following kinds are supported or in the roadmap of containerlab:
Name | Kind | Status |
---|---|---|
Nokia SR Linux | srl | supported |
Nokia SR OS | vr-sros | supported |
Arista cEOS | ceos | supported |
Arista vEOS | vr-veos | supported |
Juniper cRPD | crpd | supported |
Juniper vMX | vr-vmx | supported |
Juniper vQFX | vr-vqfx | experimental |
Cisco XRv9k | vr-xrv9k | supported |
Cisco XRv | vr-xrv | supported |
Dell FTOS | vr-ftosv | supported |
SONiC | sonic | supported |
Linux container | linux | supported |
Linux bridge | bridge | supported |
OvS bridge | ovs-bridge | supported |
mysocketio node | mysocketio | supported |
Keysight ixia-c-one | keysight_ixia-c-one | supported |
Refer to a specific kind documentation article to see the details about it.