public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Stefan Hanreich <s.hanreich@proxmox.com>
To: Thomas Ellmenreich <t.ellmenreich@proxmox.com>,
	pve-devel@lists.proxmox.com
Subject: Re: [PATCH pve-docs 1/1] network/sdn: update and clean up vlan information
Date: Thu, 1 Oct 2026 17:14:55 +0200	[thread overview]
Message-ID: <7064b7db-0a90-4516-b7a8-a83a9a9ae0cc@proxmox.com> (raw)
In-Reply-To: <20261001130839.203329-1-t.ellmenreich@proxmox.com>

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 <s.hanreich@proxmox.com>
> Signed-off-by: Thomas Ellmenreich <t.ellmenreich@proxmox.com>
> ---
> 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]]





  reply	other threads:[~2026-10-01 15:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 13:08 [PATCH pve-docs 1/1] network/sdn: update and clean up vlan information Thomas Ellmenreich
2026-10-01 15:14 ` Stefan Hanreich [this message]
2026-10-02 12:32   ` 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=7064b7db-0a90-4516-b7a8-a83a9a9ae0cc@proxmox.com \
    --to=s.hanreich@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal