Skip to content

Conversation

jbernardini
Copy link

@jbernardini jbernardini commented Aug 3, 2025

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

@steiler
Copy link
Collaborator

steiler commented Aug 4, 2025

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?!

@jbernardini
Copy link
Author

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?

@hellt hellt requested a review from Copilot August 5, 2025 22:10
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds support for Docker macvlan networks in containerlab as an alternative to the existing bridge driver. It allows users to specify macvlan configuration in topology files and automatically creates the necessary network infrastructure including host-side interfaces for container communication.

  • Adds macvlan driver support with configuration options for parent interface, mode, and auxiliary addresses
  • Implements network creation, management, and cleanup functionality for macvlan networks
  • Creates host-side macvlan interfaces to enable communication between the host and containers

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 8 comments.

File Description
types/types.go Adds macvlan-specific configuration fields to MgmtNet struct
schemas/clab.schema.json Defines JSON schema validation for new macvlan configuration options
runtime/docker/docker.go Implements macvlan network creation, validation, and cleanup logic
hostnet/macvlan.go New module handling host-side macvlan interface creation and management
Comments suppressed due to low confidence (1)

runtime/docker/docker.go:342

  • Variable name uses underscore instead of camelCase. Should be ipv6Subnet to match Go naming conventions.
	var ipv6_subnet string

@jbernardini jbernardini marked this pull request as ready for review August 5, 2025 22:48
@jbernardini
Copy link
Author

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.

@jbernardini
Copy link
Author

jbernardini commented Aug 6, 2025

# 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.

jbernardini and others added 2 commits August 5, 2025 18:46
copilot recommended consistent spacing

Co-authored-by: Copilot <[email protected]>
copilot reccomended spacing

Co-authored-by: Copilot <[email protected]>
Josh Bernardini and others added 6 commits August 5, 2025 23:12
@jbernardini
Copy link
Author

created a video demonstrating the new functionality: https://youtu.be/PfOUbXWDR74

@jbernardini
Copy link
Author

@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
Copy link
Collaborator

steiler commented Aug 11, 2025

@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!

@jbernardini
Copy link
Author

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.

@jbernardini
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants