From: "Thomas Ellmenreich" <t.ellmenreich@proxmox.com>
To: "Stefan Hanreich" <s.hanreich@proxmox.com>,
<pve-devel@lists.proxmox.com>
Subject: Re: [PATCH pve-docs v2 1/1] network/sdn: update and clean up VLAN information
Date: Wed, 21 Oct 2026 09:28:38 +0200 [thread overview]
Message-ID: <DMAC819IRQO7.3SV0Z7XI2T3F1@proxmox.com> (raw)
In-Reply-To: <b74b11bb-6309-40e1-89eb-82a09354b621@proxmox.com>
On Tue Oct 20, 2026 at 3:54 PM CEST, Stefan Hanreich wrote:
> On 10/20/26 8:45 AM, Thomas Ellmenreich wrote:
[snip]
>> +[[vlan_common_issues]]
>> +Common Issues
>> +^^^^^^^^^^^^^
>> +
>> +.Issue: Configuring VLAN on interface that is member of bridge
>> +
>> +It's not recommended to configure a VLAN on an interface that is a member of a
>> +bridge. Doing so will "blackhole" all traffic of that VLAN on the bridge.
>
> Might need a more specific example so this becomes clearer? It's hard to understand
> otherwise imo.
If I understand correctly, the example [0] you mention further down would be
an instance of 'blackholing' the traffic. Perhaps I could mention that
example here instead of creating a separate point for it.
Is this assumption correct?
>> +
>> +.Issue: Limited number of tags when VLAN offloading to NIC
>> +
>> +Certain NIC's, only support VLAN offloading only for a reduced number of tags.
>> +In these cases it is best to either reduce the VLAN tag range on the bridge or
>> +disable offloading altogether. The exact problems that can arise depend on
>> +the exact hardware used.
>
> There are two other pitfalls I can think of that can occur when configuring
> VLANs directly on top of physical interfaces:
>
>
> When using a VLAN on the host (often the management VLAN) and starting a guest
> with a network device that has the same VLAN tag set, connectivity to the host is
> lost on that VLAN after starting the guest.
>
[0]: v
> e.g.:
>
> # NIC that carries the VLANs
> iface nic1 inet manual
>
> # management VLAN
> auto nic1.1337
> iface nic1.1337 inet static
> address 10.133.7.10/24
>
> # non vlan-aware bridge
> auto vmbr1
> iface vmbr1 inet manual
> bridge-ports nic1
> bridge-stp off
> bridge-fd 0
>
> and then a guest:
>
> net0: name=eth0,bridge=vmbr1,hwaddr=BC:24:11:86:69:F3,tag=1337,type=veth
[snip]
prev parent reply other threads:[~2026-10-21 7:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 6:45 [PATCH pve-docs v2 1/1] network/sdn: update and clean up VLAN information Thomas Ellmenreich
2026-10-20 9:16 ` Michael Köppl
2026-10-20 13:54 ` Stefan Hanreich
2026-10-21 7:28 ` Thomas Ellmenreich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DMAC819IRQO7.3SV0Z7XI2T3F1@proxmox.com \
--to=t.ellmenreich@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.hanreich@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox