# Release 0.46

:material-calendar: 2023-10-08 · :material-list-status: [Full Changelog](https://github.com/srl-labs/containerlab/releases)

## 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](../manual/clabernetes/index.md) 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`.

=== "vxlan"
    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.

    ```yaml
    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
    ```

    1. The remote IP address must exist in the host network namespace.

=== "vxlan-stitch"
    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`](../cmd/tools/vxlan/create.md) command.

    ```yaml
    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
    ```

    1. 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](../manual/kinds/srl.md) node whenver you need it:

```bash
curl -sL srlinux.dev/clab-srl | clab dep -c -t -
```

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:

```bash
curl -sL srlinux.dev/clab-srl | \
  SRL_VERSION=23.3.3 SRL_TYPE=ixrd2l clab dep -c -t -
```

## Patches

### 0.46.1

* fixed `tools vxlan create` #1625.

### 0.46.2

* fixed macvlan link provisioning #1635
* added learning flag for vxlan interface #1636
