add support for bridge VLAN filter

[s3rj1k]

add support for using untagged vlans inside bridges

https://unix.stackexchange.com/a/255489

[Saruspete]

Hi,

I'd like to 👍 this request.
When you have a mixed environment with standard vlan, it can quickly become a pain:
for each vlan you want to provide on a host, you need:

• the vlan iface (eth0.$vlanid)
• a bridge over it (br$vlanid)
• a tap created by LXC over this br$vlanid bridge and the container.

Multiply this for let's say 30 VLANs (eg, your host is running an admin bastion), you have 60 ifaces, without any container running.

With the native vlan filter, we only need 1 bridge over the main interface, and you can reconfigure the vlan on the fly.

This would really be a useful and appreciated feature !

Best regards,
Adrien.

[bugz8unny69]

Hello,

Multiply this for let's say 30 VLANs (eg, your host is running an admin bastion), you have 60 
ifaces, without any container running.

Exactly, alternatively for now, macvlan seems to be the recommended approach to apply vlans on the fly.

https://github.com/lxc/lxd/issues/3375#issuecomment-362744762 suggests this is a limitation of liblxc? Can we forward this to people who are responsible for liblxc?

[Saruspete]

Oops, I worked around this with my Gentoo, with the following snippets :

Pre-activate the VLAN filtering at bridge startup (/etc/conf.d/net) :

# Enable VLAN bridge filtering 
ip link set $IFACE type bridge vlan_filtering 1
# Enable VLANs on parent ifaces
for i in {2..254}; do
  for briface in $bridge_brint; do
    bridge vlan add vid $i dev $briface master
  done
done

# Create our own iface for outside comm
ip link add name veth-host type veth peer name veth-host-c
ip link set veth-host master brint
ip link set up veth-host
ip link set up veth-host-c
bridge vlan add dev veth-host vid 8 pvid untagged master
ip a add 172.1.1.3/24 dev veth-host-c
ip r add default via 172.1.1.1 dev veth-host-c

On the LXC config, I'm using a net-script that roughly does this simplified version:

# 244:
lxc.net.44.type   = veth
lxc.net.44.flags  = up
lxc.net.44.name   = int.244
lxc.net.44.link   = brint
lxc.net.44.veth.pair    = vpgllintca.244
lxc.net.44.ipv4.address = 172.1.244.1/24
lxc.net.44.script.up    = /home/services/tools/lxc/lxc-guest-net

And the lxc-guest-net doing this simplified task ($IFACEHOSTTAP being value of lxc.net.44.veth.pair), that is the last argument of the script.up:

function set_veth_vlan {
        typeset vlan="$1"

        log "Setting vlan $vlan to lxc:$IFACEHOSTTAP host:$IFACEHOSTPARENT"

        # Set the guest as vlan 
        logexec bridge vlan add dev "$IFACEHOSTTAP" vid "$vlan" pvid untagged master
}

function do_veth_up {
        # Check if the internal iface has a . in its name
        if [[ $IFACEHOSTTAP =~ \.[0-9]+$ ]]; then
                typeset vlan="${IFACEHOSTTAP##*.}"
                log "Iface '$IFACEHOSTTAP' matches vlan $vlan"
                set_veth_vlan "$vlan"
        fi

        return 0
}

I could also push the VLAN to the bridge upon first use, that is to avoid having to pre-setup it on the init script, but didn't take the time to do the parsing of "bridge vlan show".. but that would be cleaner.

So the glue to get the vlan ID is the name of the veth pair, on the host side (lxc.net.$id.veth.pair). I didn't find any other element that could carry it for now (and don't want to do complex config parsing)

[bugz8unny69]

Oops, actually my suggestion was for LXD and the problem with this though is missing lxc.net.*.script.up.

[Saruspete]

Well, if you can't have it on LXD, that's a point to keep using plain LXC.

macvlan is not a standard solution and is quite limited.
So far, these scripts are working great on standard vlans & trunk switches.

[bugz8unny69]

The problem with LXC, issues tend to stay open indefinitely.

[s3rj1k]

@LHorace I agree we in desperate need of official hook mechanism, for now this kind of configuration can only be achieved throw hacking LXD internals.
Libvirt has hooks and no one got injured while implementing them.

[s3rj1k]

@Saruspete this is super disappointing that we can not use LXD and instead we are forced to use LXC or a bunch of hacks.

[bugz8unny69]

@s3rj1k Actually, I would rather have support for it natively than hacking scripts to accomplish the job? I open issue here, see https://github.com/lxc/lxd/issues/5627.

[bugz8unny69]

@s3rj1k Why it hasn't been implemented:

@brauner and I are the maintainers for liblxc too, the existing issue against liblxc is just fine for tracking this. We just haven't seen sufficient demand for this to justify us doing this work ourselves and nobody from the community seem to have had interest in sending a branch that implements it.

[s3rj1k]

@LHorace I am an author for this PR for LXD lxc/lxd#5182
You can easily see how long it takes to do proper PR and persuade maintainers to actually consider merging it.

[s3rj1k]

@LHorace Personally I can prepare a LXD branch with this feature added, but seeing how long it takes to contribute something to upstream I am a bit upset and demotivated.

[bugz8unny69]

I would hold off @s3rj1k before giving up. The PR seem to still be getting action though. I've seen worst. Anyway, I've to read up on IPVLAN.

[dngray]

I think I came across the same problem https://discuss.linuxcontainers.org/t/lxd-containers-on-a-vlan-aware-bridge/14734 the reason mentioned by @Saruspete #2306 (comment) is exactly the reason I don't want to add a tonne of interfaces to my server.