Add support for creating MACVLAN interfaces with "Add Interface"

Stux · November 27, 2024, 5:28am

TrueNAS should support creating and configuring a MACVLAN interface when using “Add Interface”.

Ie, MACVLAN should be an option in this menu.

This would prevent complicated CLI scripting in order to create macvlan interfaces and configuring routing tables to allow docker macvlan<->host communication.

Macvlan is supported by the Linux kernel and is a well known Linux network type

It behaves a bit like a cross between a VLAN and a Bridge.

The underlying command line to create the macvlan interface on the host is

ip link add macvlan0 link ens3 type macvlan mode bridge

Where macvlan0 is the name of the new interface, and ens3 is the parent interface. bridge is the macvlan mode, the most permissive, should be the default, but would ideally be configurable

The Linux implementation is lightweight and it eliminates the need for using a Linux bridge for sharing host access with jails and virtual machines, and importantly is supported by Docker.

The interface would allow you to pick the parent interface, possibly the macvlan mode, as well as an optional VLAN tag.

If MACVLAN interfaces could be created and configured, then you would be able to assign an IP address to a macvlan interface, much like how a Bridge network can be assigned at the moment.

For example:

This would mean that Docker macvlan containers would be able to communicate with the host, the same as virtual machines and jails can currently when using a bridge network, as documented in the below links.

YouTube - Setting up a Static IP and Network Bridge
TrueNAS Docs - Accessing NAS from a VM or Apps

For example, the following container which is on the same macvlan network as above

services:
  netshoot:
    tty: true
    image: nicolaka/netshoot
    networks:
      - macvlan0
networks:
  macvlan0:
    external: true

Can easily communicate with the TrueNAS host.

Without performing any custom routing, or command line shenanigans.

This also means that a Jailmaker jail is able to communicate with the TrueNAS host without using a bridge (note: --network-macvlan rather than --network-bridge) in the config.

Meaning that the Jail can successfully communciate with the host.

Again, not usually possible without using a bridge.

And this also means that a VM guest is able to communicate with the host without using a Bridge.

The VM is configured to use ens3 rather than a Bridge. This translates to a MACVLAN tap.

NOTE: In all examples, the Jail, Container or VM was able to communicate with the LAN, other MACVLAN clients, and the Host without using a Bridge, in a simple fashion, and network performance was also improved by bypassing the Bridge.

DHCP lease acquisition delay is also removed due to there being no need for STP on the MACVLAN bridge-like device.

NickF1227 · November 27, 2024, 6:23am

I can see the value in your overall feature request, but I think you are selling it short. A macvlan is also a little more complicated than you give it credit for.

Side note, its also the “Linux version” of a Cisco VIC which does basically the same thing in dedicated hardware (for good reason, in software things can get messy from a performance standpoint).

A MACVLAN is really a more advanced version of a BRIDGE. They both perform most of the same functions, but what seperates MACVLAN apart is that each “entity” (vm, docker container) get’s their own physical port and MAC address, e.g. eth0.0, eth0.1.

      +------------+                         +------------------------+
      |  Host NIC  |-------------------------|      Physical Network  |
      |   (eth0)   |                         |                        |
      +-----+------+                         +------------------------+
            |
      +-----+------+
      |   MACVLAN  | 
      +-----+------+
            |
      +-----+-----+-----+  
      | eth0.1 | eth0.2 | eth0.3 |   +-------------------+
      +--------+--------+--------+   | VMs / Containers  |
                                     | (Same network segment) |
                                     +-------------------+

Without getting too much more into the ramifications of what that actually means at a scale greater than homelab, I’d have concerns with just adding this as a drop down item. At least not without other considerations and UI work.

Stux · November 27, 2024, 6:28am

Oh, I understand that.

The issue is simply that TrueNAS should support it, and currently doesn’t

I hope I’ve sufficiently sold one of the use cases to justify the feature. I have also looked at how it could be implemented etc, (ie looking at the interface driver python code in middleware)

And Fangtooth’s development window is probably closing soon, and I hope this feature will be included.

NickF1227 · November 27, 2024, 6:41am

The scope of this is probably bigger than a last minute shoe in. This request is really “Lets add more managed switching functionality to TrueNAS”,

Historically, TrueNAS has never been a switch. With other forum feature requests for “XYZ VPN support” being in front of mind, this can get complicated.

etorix · November 27, 2024, 7:38am

Based on T3 #5, the window for Halfmoon feature set is closing within a month.