From: "Michael Köppl" <m.koeppl@proxmox.com>
To: "Thomas Ellmenreich" <t.ellmenreich@proxmox.com>,
<pve-devel@lists.proxmox.com>
Subject: Re: [PATCH pve-docs v2 1/1] network/sdn: update and clean up VLAN information
Date: Tue, 20 Oct 2026 11:16:02 +0200 [thread overview]
Message-ID: <DM9JVQ3LYRXN.2RQ04SVUZ1K90@proxmox.com> (raw)
In-Reply-To: <20261020064508.32479-1-t.ellmenreich@proxmox.com>
On Tue Oct 20, 2026 at 8:45 AM CEST, Thomas Ellmenreich wrote:
[snip]
> diff --git a/pve-network.adoc b/pve-network.adoc
> index 2b3e664..b1a598c 100644
> --- a/pve-network.adoc
> +++ b/pve-network.adoc
> @@ -637,6 +637,53 @@ completely done inside the guest and can not be influenced from the
> outside. The benefit is that you can use more than one VLAN on a
> single virtual NIC.
>
> +* *SDN configured VLAN:*
> +It is also possible to xref:pvesdn_config_vnet[configure VLANs in SDN] by
> +creating a VLAN zone on the bridge and then creating VNets for every VLAN tag.
> +In this case, it is also recommended to use a VLAN-aware bridge.
> +
> +.Example: SDN VLAN Zones with VLAN aware bridges
nit: VLAN-aware
> +
> +This is the preferred solution if users have a small amount of VLANs inside
> +their cluster. On every node, users should configure a VLAN-aware bridge with
> +the respective carrier for their VLANs:
> +
> +----
> +auto vmbr0
> +iface vmbr0 inet manual
> + bridge-ports nic0
[snip]
> VLAN on the Host
> ^^^^^^^^^^^^^^^^
> @@ -644,63 +691,47 @@ VLAN on the Host
> To allow host communication with an isolated network. It is possible
> to apply VLAN tags to any network device (NIC, Bond, Bridge). In
> general, you should configure the VLAN on the interface with the least
> -abstraction layers between itself and the physical NIC.
> +abstraction layers between itself and the physical NIC. But it would still
> +be best to configure the VLAN on a bridge instead of a bond or the NIC
> +directly to avoid some of the issues mentioned xref:vlan_common_issues[here].
>
> For example, in a default configuration where you want to place
> the host management address on a separate VLAN.
>
> -
> -.Example: Use VLAN 5 for the {pve} management IP with traditional Linux bridge
> +.Example: Use VLAN 5 for the {pve} management IP with VLAN aware Linux bridge
nit: VLAN-aware
> ----
> auto lo
> iface lo inet loopback
>
> iface eno1 inet manual
>
> -iface eno1.5 inet manual
> -
> -auto vmbr0v5
> -iface vmbr0v5 inet static
> - address 10.10.10.2/24
> - gateway 10.10.10.1
> - bridge-ports eno1.5
> - bridge-stp off
> - bridge-fd 0
[snip]
> -auto vmbr0
> -iface vmbr0 inet manual
> - bridge-ports eno1
> - bridge-stp off
> - bridge-fd 0
> - bridge-vlan-aware yes
> - bridge-vids 2-4094
> +----
> +net0: name=eth0,bridge=vmbr0,tag=5,...
> ----
>
> The next example is the same setup but a bond is used to
> make this network fail-safe.
>
> -.Example: Use VLAN 5 with bond0 for the {pve} management IP with traditional Linux bridge
> +.Example: Use VLAN 5 with bond0 for the {pve} management IP with VLAN aware Linux bridge
nit: VLAN-aware
> ----
> auto lo
> iface lo inet loopback
> @@ -716,24 +747,72 @@ iface bond0 inet manual
> bond-mode 802.3ad
> bond-xmit-hash-policy layer2+3
>
> -iface bond0.5 inet manual
[snip]
> +auto vmbr0.5
> +iface vmbr0.5 inet static
> + address 10.10.10.2/24
> + gateway 10.10.10.1
> +
> ----
>
> +Troubleshooting
> +^^^^^^^^^^^^^^^
> +
> +There are some helpful commands that can be utilised when debugging such issues:
nit: usually US English, so "utilize". A quick grep also suggests we do
no use "utilise" anywhere.
> +
> +----
> +$ bridge -compressvlans vlan show
> +----
> +
[snip]
> +----
> +$ bridge fdb show
> +----
> +
> +This prints a list of the current forwarding database entries of all bridges.
> +The bridge decides how to forward a given packet based on this table. An entry
> +of the fdb generally looks like this:
> +
> +----
> +aa:aa:aa:d8:36:7c dev nic0 vlan 49 master vmbr0 permanent
> +----
> +
> +This means that packets arriving on vmbr0, that have VLAN Tag 49 set and
> +destination MAC address aa:aa:aa:d8:36:7c will get forwarded to the port nic0.
Is this correct? According to the docs [0], permanent is a synonym for
local. So wouldn't this mean that packages with this destination address
are NOT forwarded, but handled locally? Or am I misinterpreting this?
[0] https://www.man7.org/linux/man-pages/man8/bridge.8.html
> +
> +[[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.
> +
> +.Issue: Limited number of tags when VLAN offloading to NIC
> +
> +Certain NIC's, only support VLAN offloading only for a reduced number of tags.
nit: "NICs"
nit: the comma should also be removed
nit: theres 2 "only"s
> +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.
> +
> Disabling IPv6 on the Node
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> diff --git a/pvesdn.adoc b/pvesdn.adoc
> index 3fd3533..8e40ab4 100644
> --- a/pvesdn.adoc
> +++ b/pvesdn.adoc
> @@ -251,7 +251,7 @@ the network segments. This allows connectivity of VMs between different nodes.
> VLAN zone configuration options:
>
> Bridge:: The local bridge or OVS switch, already configured on *each* node that
> - allows node-to-node connection.
> + allows node-to-node connection. This bridge should be VLAN aware to work properly.
nit: VLAN-aware
>
>
> [[pvesdn_zone_plugin_qinq]]
next prev parent reply other threads:[~2026-10-20 9:16 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 [this message]
2026-10-20 13:54 ` Stefan Hanreich
2026-10-21 7:28 ` Thomas Ellmenreich
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=DM9JVQ3LYRXN.2RQ04SVUZ1K90@proxmox.com \
--to=m.koeppl@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.ellmenreich@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