VLAN aware bridges and untagged traffic

[Steffen Zieger]

Hi Ganeti users,

I wonder if anyone uses VLAN aware bridges and seeing untagged traffic within an instance.

When adding a tap interface to a bridge, it's using "pvid untagged" [1]:
bridge vlan add dev tap17 vid 4001 pvid untagged master

But it seems, it's not removing vid 1, which is getting added by default and which is the reason, why I'm seeing traffic from vid 1. 
Executing
bridge vlan del dev tap17 vid 1

will do the proper thing.

Is there a proper solution for this? 

Best,

Steffen

[1]: https://github.com/ganeti/ganeti/blob/2782c6ed8a850c86448b105ae6ed8d06f6b8723a/tools/net-common.in#L130

--

Steffen Zieger
Teamleiter Infrastruktur
Ströer Online Marketing
Rotebühlstraße 50, 70178 Stuttgart
E-Mail: steffen...@stroeer-online-marketing.de
Fon: (0711) 128 501 666

RegioHelden GmbH | https://stroeer-online-marketing.de
Sitz der Gesellschaft: Stuttgart
Registergericht: Amtsgericht Stuttgart, HRB 733189
Geschäftsführer: Dr. Andreas Müller-Leydig, Christoph Kreuzer

Datenschutz Pflichtinformationen gemäß Artikel 12 ff. DSGVO zur Verarbeitung personenbezogener Daten entnehmen Sie bitte unserer Datenschutzerklärung unter https://stroeer-online-marketing.de/dsgvo

[Sascha Lucas]

Hi Steffen,

On Mon, 23 Mar 2026, 'Steffen Zieger' via ganeti wrote:

> I wonder if anyone uses VLAN aware bridges and seeing untagged traffic
> within an instance.

I use it.

> When adding a tap interface to a bridge, it's using "pvid untagged" [1]:
> bridge vlan add dev tap17 vid 4001 pvid untagged master
>
> But it seems, it's not removing vid 1, which is getting added by default
> and which is the reason, why I'm seeing traffic from vid 1.
> Executing
> bridge vlan del dev tap17 vid 1
> will do the proper thing.
>
> Is there a proper solution for this?

> [1]:
> https://github.com/ganeti/ganeti/blob/2782c6ed8a850c86448b105ae6ed8d06f6b8723a/tools/net-common.in#L130

Your observation is correct. And Ganeti does not address the problem.
Instead it silently delegates the solution to the admin, by setting
"bridge vlan del dev gnt-bridge vid 1 self" in the system startup
scripts[2].

This would not prevent the default VLAN "1 Egress Untagged" on the tap
interface, but should stop unwanted communication via VLAN 1 on the
bridge???

The gnt-instance man page could be more precise on this.

Thanks, Sascha.

[2] https://github.com/ganeti/ganeti/issues/1670#issuecomment-1098182623

[Sascha Lucas]

On Tue, 24 Mar 2026, 'Sascha Lucas' via ganeti wrote:

> Your observation is correct. And Ganeti does not address the problem. Instead
> it silently delegates the solution to the admin, by setting "bridge vlan del
> dev gnt-bridge vid 1 self" in the system startup scripts[2].
>
> This would not prevent the default VLAN "1 Egress Untagged" on the tap
> interface, but should stop unwanted communication via VLAN 1 on the bridge???
>
> The gnt-instance man page could be more precise on this.
>

> [2] https://github.com/ganeti/ganeti/issues/1670#issuecomment-1098182623

Further investigation shows, that it is possible to disable default VLAN 1
on a bridge by:

ip link set dev gnt-br type bridge vlan_filtering 1 vlan_default_pvid 0

This way all added tap interfaces won't have VLAN 1 per default. Seems
much better than purposed above.

The above line is suitable for ifupdown post script. With systemd-networkd
my bridge looks like this:

# cat /etc/systemd/network/gnt-br.netdev
[NetDev]
Name=gnt-br
Kind=bridge

[Bridge]
VLANFiltering=yes
DefaultPVID=none
ForwardDelaySec=0
STP=no

# cat /etc/systemd/network/gnt-br.network
[Match]
Name=gnt-br

[Network]
LinkLocalAddressing=no
DHCP=no

Again, removing VLAN 1 from the bridge can break node networking, if you
have an IP assigned to the bridge.

Thanks, Sascha.

[Steffen Zieger]

Hey Sascha,

thank you for your response. I guess, your suggested solution might work in some cases, but not all.
There might be untagged traffic, which should be received by one instance, but not the other.

Maybe I'm reading the docs wrong here:
"in bridged and openvswitch mode specifies the VLANs that the NIC will be connected to. To connect as an access port use n or .n with n being the VLAN ID. To connect as an trunk port use :n[:n]. A hybrid port can be created with .n:n[:n]. For bridged mode, the bridge needs VLAN filtering enabled. Assuming a bridge named gnt-br, this is accomplished by running ip link set dev gnt-br type bridge vlan_filtering 1."

My expectation would be to have a NIC which is connected to a single VLAN as access port, if VLAN ID is set to e.g. 4000 or .4000 (reading the code, "4000" will be converted to ".4000").

I wonder if I should send a PR to improve the docs or try to come up with a fix, which will remove VID 1 if a specific VLAN ID is being set.

Besides that, thanks again for a possible way to solve this issue!

Thanks,

Steffen

--
You received this message because you are subscribed to the Google Groups "ganeti" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ganeti+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ganeti/11158708-b053-9d07-164d-6e8250ce16df%40web.de.

[Sascha Lucas]

Hi Steffen,

to avoid misunderstandings, I return to your original question:

On Mon, 23 Mar 2026, 'Steffen Zieger' via ganeti wrote:

> But it seems, it's not removing vid 1, which is getting added by default
> and which is the reason, why I'm seeing traffic from vid 1.
> Executing
> bridge vlan del dev tap17 vid 1
> will do the proper thing.
>
> Is there a proper solution for this?

So if "bridge vlan del dev tap17 vid 1" solves your problem, then setting
up your vlan-aware bridge with "ip link set dev gnt-br type bridge
vlan_filtering 1 vlan_default_pvid 0" will solve the problem, too. IMHO it
solves this at the root cause and makes removal at each individual tap
interface obsolete.

On Tue, 24 Mar 2026, 'Steffen Zieger' via ganeti wrote:

> thank you for your response. I guess, your suggested solution might work
> in some cases, but not all.

Yes, probably.

> There might be untagged traffic, which should be received by one instance,
> but not the other.
>
> Maybe I'm reading the docs wrong here:
> "in bridged and openvswitch mode specifies the VLANs that the NIC will be
> connected to. To connect as an access port use n or .n with n being the
> VLAN ID. To connect as an trunk port use :n[:n]. A hybrid port can be
> created with .n:n[:n]. For bridged mode, the bridge needs VLAN filtering
> enabled. Assuming a bridge named gnt-br, this is accomplished by running ip
> link set dev gnt-br type bridge vlan_filtering 1."
>
> My expectation would be to have a NIC which is connected to a single VLAN
> as access port, if VLAN ID is set to e.g. 4000 or .4000 (reading the code,
> "4000" will be converted to ".4000").

That expectation is right and the idea behind. It just depends on how you
setup your bridge. If doing nothing, vlan-id "1 Egress Untagged" will be
there additionally to your primary VLAN i.e 4000. If setting up with
"vlan_default_pvid 0", VLAN 1 won't be present.

> I wonder if I should send a PR to improve the docs or try to come up with a
> fix, which will remove VID 1 if a specific VLAN ID is being set.

The docs could definitively be improved. Always removing VID 1 sounds like
a way for the lazy admin, but might destroy unforeseen network setups???

Thanks, Sascha.