Bridge and VLAN trunk

[Laine Stump]

On 3/11/21 5:53 AM, Gionatan Danti wrote:
> Dear list,
> I am a question about the best use of bridge, vlan trunk and libvirt.
> 
> When dealing with virtual machies bound to specific vlan, I generally 
> use a straightforward approach:
> eth -> bridge -> vm (for untagged traffic)
> eth -> eth.10 -> bridge -> vm
> eth -> eth.nn -> bridge -> vm
> 
> Now I am faced with enabling vlan trunking for a specific vm (a 
> virtualized firewall). The simpler approach would be:
> eth -> bridge -> vm (for the vm needing trunk)
> eth -> bridge.10 -> macvtap -> vm
> 
> The issue with the above method is that any VM on the main untagged vlan 
> needs to be bound to the "plain" bridge, having access to *any* traffic 
> of *any* other vlan. If this is ok (and the desired behavior) for the 
> firewall, it is clearly wrong for the other VMs.
> 
> A simple fix would be to use ebtables to block/drop vlan tagged traffic 
> on the main bridge for any virtual adapter except the required one (ie: 
> the firewall virtual interface). It works, but I wounder if other 
> preferred approaches exists.
> 
> For example, I tested another more convoluted setup:
> eth -> bridge -> firewall vm
> eth -> bridge.10 -> macvtap -> vm
> eth -> bridge -> veth0 -> veth1 -> other bridge with vlan filtering on 
> -> vm
> 
> The last row show the use of veth virtual interface, configurable via ip 
> link. Enabling vlan filtering on the second bridge (rather than on the 
> first) is to keep vlan filtering simple: rathen than enabling all 
> required vlan on the first bridge, I simply enable only untagged traffic 
> on the second one.
> 
> Does libvirt support bridge vlan filtering natively? Reading the docs, 
> it seems to the supported only on OpenVSwitch or SRV-IO based adapter.

That's correct. Support was added to the Linux host-bridge device a few 
years ago for per-port VLAN tagging/filtering, but there hasn't been 
anyone sufficiently compelled (by their own needs or by their altruistic 
instincts) to support that. It likely would be fairly straightforward to 
do once someone dove into it - all the necessary config attributes are 
already there, so it would just involve recognizing and acting on them 
when a guest interface connected to a bridge that was a standard Linux 
host bridge (of course in reality there will likely be some unexpected 
incompatibility that will make it more difficult, but at least *in 
theory* it would be simple).

So, if you can program in C and are willing to dig into the online docs 
for setting per-port attributes for Linux host bridges and implementing 
them (iirc via sending netlink messages) then feel free to start 
hacking, and check in on irc.oftc.net in the #virt channel if you have 
questions. Otherwise, I would recommend installing Open vSwitch. I don't 
have a link handy, but I've seen a few HOWTOs floating around, and 
followed one of them a few years ago to set it up on Fedora and RHEL 
test machines.