srl-labs
Macvlan support
Allows the user to specify in topology file, and containerlab to create, a mgmt network using the docker macvlan driver. Working and tested. Also creates the host networking on linux to support current host-to-device ssh behavior.
More context here: https://discord.com/channels/860500297297821756/1400987584460755165
Hi @jbernardini, I'm wondering if that logic should not in general move somewhere e.g. in utils or so... I ssume it could be reused for podman also?!
Hi @jbernardini, I'm wondering if that logic should not in general move somewhere e.g. in utils or so... I ssume it could be reused for podman also?!
the host network adapter/route logic? I agree and will work to pull it out now that I've got it all working. Also, do you have any examples of platform specific code? That piece should only go in the linux build atm.
do you also mean the docker macvlan network creation?
Everything seems to be working on create and delete, whether the macvlan network needs to be created or already exists. This is nice because if someone needs something a little more complex they can just use docker native tools to create the network and clab will consume it. That's good because this does not provide full coverage of the docker macvlan capabilities, but provides the simplest way to get a lab up with management IPs reachable from your network. That does make it super easy to spin up duplicate IP addresses on the network if you're not careful.
The host network adapter/route operations are all moved out to a hostnet package. Subnets and routing get's a little complicated and I've tried to add some guidance in the logs. Will want some solid documentation around this. To facilitate the easiest option - as in, you don't have to do anything and it'll just work- I've allowed a CIDR address into the aux-address input. That lets you set the macvlan subnet to the host's subnet so container <=> network communications are automatic, but also build a static route on a smaller subnet from the host to the containers which is otherwise blocked by the kernel with macvlan.
I haven't looked closely at the podman or containers runtimes yet but the docker macvlan driver networking seems correctly placed in docker.go, along side the docker bridge driver networking.
# Example: Using CIDR notation to avoid route conflicts
# Host is on 192.168.1.0/24, containers use same subnet but route only a /26
name: macvlan-cidr-aux
mgmt:
network: clab-macvlan
driver: macvlan
macvlan-parent: eth0
ipv4-subnet: 192.168.1.0/24 # Host subnet for automatic networking
ipv4-gw: 192.168.1.1 # Same gateway as host
macvlan-aux: 192.168.1.129/26 # Creates static route any subnet smaller than the host subnet
# This configuration:
# - Allows containers to communicate on the containerlab host network
# - Routes /26 through the host macvlan interface
# - to avoid conflict with existing .0/24 route on the host
# - container IPS should be from the smaller subnet /26 in this example.
# - Could implement the docker macvlan address range to facilitate that.
created a video demonstrating the new functionality: https://youtu.be/PfOUbXWDR74
@steiler I have the changes now ready for podman to support macvlan on the mgmt network. Okay to update this PR because they are dependent on the hostnet/macvlan.go additions in this PR? Or would you rather another PR for podman?
@steiler I have the changes now ready for podman to support macvlan on the mgmt network. Okay to update this PR because they are dependent on the hostnet/macvlan.go additions in this PR? Or would you rather another PR for podman?
Thats on @hellt to decide. But thanks for the effort already!
I've got a bug in the network destroy code that'll recreate the network on destroy if it doesn't exist. Thought I'd fixed that but must have reintroduced it somehow. Will update.
I've got a bug in the network destroy code that'll recreate the network on destroy if it doesn't exist. Thought I'd fixed that but must have reintroduced it somehow. Will update.
resolved
Hello @hellt, Should I resolve the conflicts to keep this moving? I figured they were at least in part due to the command refactor and maybe someone else would want to look at them?
Yes, sorry it has been a busy month with some work related PRs getting priority. If you resolve the issues I will have a look
