Understanding the state of containerlab on ARM Macs

[neilschark]

Hi,

I am a happy containerlab user for more than a year and now have a M1 mac from work.

Two days ago there were changes to the documentation regarding ARM Macs: #1617

While still not supported by containerlab directly, the solutions docker-in-docker or a x86 VM are highlighted in the documentation. But I don't understand what is missing from using containerlab on an ARM Mac "more natively", instead of using a Linux VM or did setup.

I can use Docker Desktop and start the Arista x86 cEOS images I use for work with the docker flag --platform linux/amd64. Of course, as docker is a VM on MacOS, there is still an abstraction layer compared to Linux, but from a user perspective it's not really there, as you don't have to manually configure this setup, e.g. port forwarding, etc.

Could you help me understand what is still missing from making containerlab available for MacOS directly? If it's not a technological problem, but rather just a "sombeody has to do it"-issue, we would be happy to help and give something back to containerlab, as we use it a lot at our university project.

[hellt]

Hi @neilschark
Great to hear you are a happy containerlab user!

The problem with native support of containerlab on mac has several angles:

1. to be able to use containerlab natively on mac we need to build a binary for OS=darwin, but we can't quite do that, because clab relies on linux's netlink/rtnetlink APIs to create veth links, tune networking parameters, interact with bridges, etc.

2. second angle is image availability for ARM architecture. Since M1/2 chips are ARM based any non-ARM network OS image will run using virtualization/translation from X86 to ARM. While some images can work with that mode (like ceos that you mentioned), some won't. For instance all VM-based images will not start up in that mode.

[neilschark]

Hi,

thanks for your fast reply.

1. I noticed that building containerlab on MacOS failed because of some errors related to networking. I think that this is exactly what you mentioned? As far as I understand the problem it means that an MacOS compatible alternative must be implemented into containerlab first?
2. I forgot about the wide variety of supported operating systems for the images. As I am only working with arista docker images I looked at it to narrow. 😁

So to summarize my understanding is: There are too few images available/working on ARM and as such the user base is too small for the core team to put the resources into programming a MacOs compatible version of containerlab?