VLAN support in bridge network driver

[ahinrichs]

Feature request description

With podman + netavark it is currently not possible to create veth links with VLAN tags.

I use the linux bridge in VLAN-aware mode to interconnect different container/VMs (podman, libvirt, lxc, systemd-nspawn). To connect podman container to a specific VLAN I use the CNI bridge plugin in L2-only vlan configuration.

Suggest potential solution

It would need two changes:

1. Support multiple networks with the same network_interface but different vlan option
2. Set the vlan on the veth link:
   sudo bridge vlan add vid 20 pvid untagged dev veth1

1. network creation

Currently, the podman network create already allows to set a vlan option:

$ podman network create -o 'com.docker.network.bridge.name=brint' \
        -o vlan=20 --ipam-driver 'none' vlan20

gives /etc/containers/networks/vlan20.json

{
  "name": "vlan20",
  "driver": "bridge",
  "network_interface": "brint",
  "options": {
    "vlan": "20"   <--- 
  },
  "ipam_options": {
    "driver": "none"
  }
}

But it fails to create another network on the same bridge:

$ sudo podman network create -o 'com.docker.network.bridge.name=brint' \
        -o vlan=30 --ipam-driver 'none' vlan30
Error: bridge name brint already in use

2. container startup / link creation

When using a network, the vlan option currently is ignored:

$ sudo podman run --rm -dit --net vlan20 alpine sh
f10492164ec16b69a2216bdcfe9e78812ab5a90865937ca95ec6a6f32064cdaa
$ bridge vlan
port              vlan-id
[...]
veth1             1 PVID Egress Untagged

With CNI (or libvirt, lxc, ...) it works as expected:

$ bridge vlan
port              vlan-id
veth1             1 Egress Untagged
                  20 PVID Egress Untagged

Have you considered any alternatives?

I used to use CNI and custom shell based plugins. As CNI is considered deprecated I try to recreate my setup. Netavark and its support for multiple static interfaces is great but the lack of VLAN support in podman currently a stopper for me. So I need to stick with CNI for now.

Additional context

From the podman network create manpage:

--opt, -o=option

Set driver specific options.

Additionally the bridge driver supports the following options:

• vlan: This option assign VLAN tag and enables vlan_filtering. Defaults to none.
• com.docker.network.bridge.name: This option assigns the given name to the created Linux Bridge

[Luap99]

This has to be implemented netavark so I move the issue there.

[ahinrichs]

For 1. the code is in a different repo common, func createBridge, line 16

[Luap99]

yes but until it is implemented in netavark (PRs welcome) there is no point in allowing that in c/common/libnetwork

[chriss-de]

I have the same problem.
For me this looks like a new network driver - sth like "brat" as in bridge attach

I have a (and only one) bridge interface on my system with multiple VLANs. For me it would be perfect to have a podman network that just adds the vnet interface to my existing bridge and configure the VLANs

[Luap99]

I don't think we need a new driver, with the latest code we have mode=unmanaged support in the bridge driver which allows you to use an existing bridge without any of our firewall code.

So all netavark would have to do then is to enable vlan filtering on the bridge if not already? And then assign the vlan number to the host side veth when attaching it to the bridge, correct?

[chriss-de]

yes - pretty much what I would need for my use case. the less changes on the existing bridge the better.

[ahinrichs]

Would solve my use case to. Leave the bridge as it is and add the host veth with vlan tag to it.

[chriss-de]

This ’mode=unmanaged’ - is it available in a version or is it just in main?

[Luap99]

Just in main, it will be part of the next version 1.14

[chriss-de]

Thanks
I'm on 1.13.1 - I'll wait before switching some binaries around

[Luap99]

So I have written code locally to enable the vlan, it was much less than I thought.

The one open question is by default the interface stays connected to vlan 1. Looking at cni they seem to have an option called preserveDefaultVlan which defaults to true so same as your example and my code but it is possible to remove from vlan 1 with that I would assume.
Is that something you would need/care about? I guess I just push my code as is (only need to add test) and we cloud add such option in a follow up if requested by any users.

[chriss-de]

Well in my current setup it probably would not break as I don't use vlan1.
But I would feel better if the interface were only assigned to vlans I want.
So with that option you found in the cni code it would be nicer.

Does your code allow multiple vlans?

[Luap99]

The code currently only allows one vlan which AFAICT matches the cni vlan option.

The goal with the original report here at least would to have one bridge but then several networks that use the same bridge and different vlan ids. Then you just connect the container two the two networks and they would have access two both vlans via two different veth pairs.

If we were to allow more than one vlan on a interface we cannot use an untagged container interface.

[chriss-de]

Yes all good. I was just curious what will be possible.

Thank you for your code and work

[Luap99]

I think the default vlan comes down to the vlan_default_pvid options which defaults to 1. If I understand it correctly you can set this to 0 on the bridge then no default vlan is assigned.

[Luap99]

PR #1161, testers welcome.

You can manually edit the network config files to add "mode": "unmanaged" to the options and allow you to create several network config files with the same bridge.

Once the stuff is merged here I will fixup podman network create to allow such configs to be created via the cli.

[ahinrichs]

I will try to test.

If one set vlan_default_pvid 0 on the bridge, then no vlan is added implicitly and only the explicit added vlans are active.

[chriss-de]

I have tested it. Works as advertised. Good work.

Thanks again.