From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id ADA171FF0A3 for ; Thu, 01 Oct 2026 17:15:03 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id CA65C2170D; Thu, 01 Oct 2026 17:15:00 +0200 (CEST) Message-ID: <7064b7db-0a90-4516-b7a8-a83a9a9ae0cc@proxmox.com> Date: Thu, 1 Oct 2026 17:14:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH pve-docs 1/1] network/sdn: update and clean up vlan information To: Thomas Ellmenreich , pve-devel@lists.proxmox.com References: <20261001130839.203329-1-t.ellmenreich@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: <20261001130839.203329-1-t.ellmenreich@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.667 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 4PCBKT7RI3AZYUDEILDTJRBWQ3N6N5TF X-Message-ID-Hash: 4PCBKT7RI3AZYUDEILDTJRBWQ3N6N5TF X-MailFrom: s.hanreich@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Thanks for looking into this! On 10/1/26 3:08 PM, Thomas Ellmenreich wrote: > Adjusted some of the details related to VLAN setups, both with the traditional > methods as well as the SDN setup. > > - Removed an outdated example and added more information to the remaining > examples. First, by adding the VLAN interface on the bridge and then > showcasing that VLAN tags can be set in the guest network configurations. > > - Noted that, for setups using a bond connected to VLAN aware bridge, > creating VLAN interfaces should be done on the bridge and not the bond. > > - Added SDN as a possible way to configure VLANs for guests. > > Suggested-by: Stefan Hanreich > Signed-off-by: Thomas Ellmenreich > --- > As discussed off list, some improvements to the VLAN related documentation > were necessary. Not sure if my wording is correct as is. > > pve-network.adoc | 67 ++++++++++++++++++++---------------------------- > pvesdn.adoc | 2 +- > 2 files changed, 29 insertions(+), 40 deletions(-) > > diff --git a/pve-network.adoc b/pve-network.adoc > index 2b3e664..a00956a 100644 > --- a/pve-network.adoc > +++ b/pve-network.adoc > @@ -637,6 +637,11 @@ 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:* > +Aside from manually configuring the network stack, it is also possible to > +configure VLANs by creating a VNet in the SDN configuration. A local network > +interface with the same name is then available on each node. For more > +information, see xref:pvesdn_config_vnet[here]. Maybe something like this would be better: [..] it is also possible to configure VLANs in SDN by creating a VLAN zone on the bridge and then create VNets for every VLAN tag. In this case, it is also recommended to use a VLAN-aware bridge. > VLAN on the Host > ^^^^^^^^^^^^^^^^ > @@ -649,52 +654,34 @@ abstraction layers between itself and the physical NIC. > 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 > ---- > 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 > - > auto vmbr0 > iface vmbr0 inet manual > bridge-ports eno1 > bridge-stp off > bridge-fd 0 > - > ----- > - > -.Example: Use VLAN 5 for the {pve} management IP with VLAN aware Linux bridge > ----- > -auto lo > -iface lo inet loopback > - > -iface eno1 inet manual > - > + bridge-vlan-aware yes > + bridge-vids 2-4094 > > auto vmbr0.5 > iface vmbr0.5 inet static > address 10.10.10.2/24 > gateway 10.10.10.1 > +---- > > -auto vmbr0 > -iface vmbr0 inet manual > - bridge-ports eno1 > - bridge-stp off > - bridge-fd 0 > - bridge-vlan-aware yes > - bridge-vids 2-4094 > +Guests can then reference the VLAN tag directly in their network > +configuration. Compared to an SDN-configured solution, this has the > +disadvantage that specific VLANs cannot be named, but the advantage that > +each VLAN does not have to be configured individually. > + > +---- > +net0: name=eth0,bridge=vmbr0,tag=5,... > ---- > > The next example is the same setup but a bond is used to > @@ -716,24 +703,26 @@ iface bond0 inet manual > bond-mode 802.3ad > bond-xmit-hash-policy layer2+3 > > -iface bond0.5 inet manual > - > -auto vmbr0v5 > -iface vmbr0v5 inet static > - address 10.10.10.2/24 > - gateway 10.10.10.1 > - bridge-ports bond0.5 > - bridge-stp off > - bridge-fd 0 > - > auto vmbr0 > iface vmbr0 inet manual > bridge-ports bond0 > + bridge-vlan-aware yes > + bridge-vids 2-4094 > bridge-stp off > bridge-fd 0 > > +auto vmbr0.5 > +iface vmbr0.5 inet static > + address 10.10.10.2/24 > + gateway 10.10.10.1 > + > ---- > > +Please note that when using a bond with a VLAN-aware bridge, the VLAN > +interface should be created on the bridge and not on the bond. Configuring the > +VLAN interface on the bond can cause issues for the traffic arriving on > +the bond. Maybe we could make that a general warning? Configuring a VLAN on an interface, that is member of a bridge, will "blackhole" all traffic of that VLAN on the bridge. > Disabling IPv6 on the Node > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > > diff --git a/pvesdn.adoc b/pvesdn.adoc > index 3fd3533..a515a13 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 brige should be VLAN aware to work properly. > > > [[pvesdn_zone_plugin_qinq]]