Release 0.46#
2023-10-08 ยท Full Changelog
Declarative VXLAN links handling#
In #1532 @steiler added a couple of new link types - vxlan
and vxlan-stitch
that allow users to declaratively define VXLAN links between nodes.
Our Clabernetes project will use the vxlan-stitch
link type to declaratively define links between network elements on different worker nodes.
Note
The default vxlan port is 14789
.
The vxlan
link type creates a VXLAN link in the host network namespace and moves it to the node's netns as if this link belongs to the node itself.
name: vxlan-embed
topology:
nodes:
srl1:
kind: nokia_srlinux
image: ghcr.io/nokia/srlinux
links:
- type: vxlan
endpoint:
node: srl1
interface: e1-1
mac: 02:00:00:00:00:04
remote: 172.20.25.22 #(1)!
vni: 100
udp-port: 14788
- The remote IP address must exist in the host network namespace.
The vxlan-stitch
mode creates vxlan link in the host netns, but contrary to vxlan
link type it doesn't move the link to the node's netns; instead it creates a veth link between the node and the host, and uses tc redirect rules to stitch the veth link to the vxlan link.
This is exactly the same approach as used by the tools vxlan create
command.
name: vxlan-stitch
topology:
nodes:
srl1:
kind: nokia_srlinux
image: ghcr.io/nokia/srlinux
links:
- type: vxlan-stitch
endpoint:
node: srl1
interface: e1-1
mac: 02:00:00:00:00:04
remote: 172.20.25.22 #(1)!
vni: 100
udp-port: 14788
- The remote IP address must exist in the host network namespace.
Containerlab on Apple M1/M2#
Systems that requires specific x86 CPU flags or nested virtualization may be launched with a UTM/Qemu VM as documented in the newly added Apple MacOS and ARM chapter.
We prepared the UTM image with containerlab installed to make it easier to get started running CPU-picky systems on Apple M1/M2.
Stdin topologies#
Now when #1621 is merged, you can pass the topology definition via stdin. This opens up a lot of possibilities for automation and integration with other tools. Most common use case is to use curl
to fetch a remote topology and immediately pass it to containerlab.
For example, this is how you can spin up a topology with a single SR Linux node whenver you need it:
Couple that with containerlab' ability to use env variables in the topology file and you have a clever way to spin up parametrized topologies with a single command:
Patches#
0.46.1#
- fixed
tools vxlan create
#1625.