From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 28F9A1FF141 for ; Mon, 30 Mar 2026 23:48:41 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 971FC97C6; Mon, 30 Mar 2026 23:49:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=rchrist.io; s=default; t=1774906787; bh=hwuF5abdL/rpGZGDyTrmS5Td/RF4/1uEVW08hdttUPs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MmEmdYAp1j5MfH8C/I3+m9k7TLyq6J8/VRi60iC+m9oXBat9+oMwWqHUoXS8f0L68 MUSMiNTtO7UwyQGHdVxbxEhe1MGxHRcfKWqn7mr1U7jLRCrYpqFGDx6uYmgV/FOchB xl2SF9kjj2q+BpZKGfXwYp9927BNyYi5cwG6wUFRWwBtmk4AmFrWEqjxNztg7Vpqj0 UH1b4U5Bb/cT3gw2+tviUFYqBCwiObkFZ9lxEHZrQyuMwMCY4V80cikEkVgb0SCTRl gbzLgO2H1j9uxGa/rrUTYp6U6IuCvqwio/JMJ4j3cIesP3mdZfYSstxNJBQ4/DSZkk X8jYNBe36hHKw== From: Robin Christ To: pve-devel@lists.proxmox.com Subject: [PATCH ifupdown2 4/4] bridge: Fix multiple Single VXLAN Devices in bridge not having tunnel_info applied on first run Date: Mon, 30 Mar 2026 23:39:21 +0200 Message-ID: <20260330213921.533853-5-robin@rchrist.io> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260330213921.533853-1-robin@rchrist.io> References: <20260330213921.533853-1-robin@rchrist.io> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_MISSING 0.1 Missing DMARC policy RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust SPF_HELO_PASS -0.001 SPF: HELO matches SPF record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: NH6SSHK46ADUTSSOPCNY2ZI2KHCKJWR2 X-Message-ID-Hash: NH6SSHK46ADUTSSOPCNY2ZI2KHCKJWR2 X-MailFrom: robin@rchrist.io 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 CC: Robin Christ X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Robin Christ If you add multiple Single VXLAN Devices to a bridge, only the last one would get the proper tunnel_info applied, ultimately resulting in a non-functional network setup. This could be fixed by a second execution of ifupdown2. The reason for this was that the original code was not written with multiple Single VXLAN Devices in a single bridge in mind, thus it had only the variable single_vxlan_device_ifaceobj storing a single interface that would control the application of tunnel_info the bridge's SVDs. Replacing the variable against a list single_vxlan_device_ifaceobjs and adding another little loop fixes the issue. Additionally, some very exhaustive, clarifying information has been added Signed-off-by: Robin Christ --- ...tiple-single-vxlan-devices-in-bridge.patch | 101 ++++++++++++++++++ debian/patches/series | 1 + 2 files changed, 102 insertions(+) create mode 100644 debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch diff --git a/debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch b/debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch new file mode 100644 index 0000000..1374426 --- /dev/null +++ b/debian/patches/pve/0019-bridge-fix-multiple-single-vxlan-devices-in-bridge.patch @@ -0,0 +1,101 @@ +From: Robin Christ +Date: Mon, 30 Mar 2026 21:07:41 +0200 +Subject: bridge: Fix multiple Single VXLAN Devices in bridge not having + tunnel_info applied on first run + +If you add multiple Single VXLAN Devices to a bridge, only the last one would get the proper +tunnel_info applied, ultimately resulting in a non-functional network setup. +This could be fixed by a second execution of ifupdown2. + +The reason for this was that the original code was not written with multiple Single VXLAN Devices +in a single bridge in mind, thus it had only the variable single_vxlan_device_ifaceobj storing +a single interface that would control the application of tunnel_info the bridge's SVDs. +Replacing the variable against a list single_vxlan_device_ifaceobjs and adding another little +loop fixes the issue. + +Additionally, some very exhaustive, clarifying information has been added + +Signed-off-by: Robin Christ +--- + ifupdown2/addons/bridge.py | 54 +++++++++++++++++++++++++++++++++++++++++++--- + 1 file changed, 51 insertions(+), 3 deletions(-) + +diff --git a/ifupdown2/addons/bridge.py b/ifupdown2/addons/bridge.py +index dee6f7b..5918c94 100644 +--- a/ifupdown2/addons/bridge.py ++++ b/ifupdown2/addons/bridge.py +@@ -2145,7 +2145,51 @@ class bridge(Bridge, moduleBase): + + def up_apply_brports_attributes(self, ifaceobj, ifaceobj_getfunc, bridge_vlan_aware, target_ports=[], newly_enslaved_ports=[]): + ifname = ifaceobj.name +- single_vxlan_device_ifaceobj = None ++ # Historically, "Single VXLAN Device" was chosen to name the concept of having ++ # a single VXLAN interface with "external" flag in ip link (Kernel VXLAN_F_COLLECT_METADATA) ++ # that is also the only VXLAN interface slave of the bridge. This VXLAN interface ++ # would terminate all the VNIs for the bridge, improving scalability a lot, as now you ++ # don't have to create a VXLAN interface for each VNI. ++ # In the beginning, you could only ONE Single VXLAN device per UDP-Port on the entire system. ++ # However, it was recognized that there may be the need to have multiple "Single VXLAN Devices" ++ # on your system, and in kernel commit f9c4bb0b245cee35ef66f75bf409c9573d934cf9 the possibility ++ # to have multiple SVD's was added, but it requires the "vnifilter" flag (kernel VXLAN_F_VNIFILTER) ++ # ++ # But even with Single VXLAN Devices at hand, there are valid scenarios where you may want to have multiple ++ # Single VXLAN Devices on the same bridge! One scenario could be traffic steering in BGP-to-the-host ++ # setups, where you don't want separate bridges per VXLAN interface (e.g. because customer VMs don't ++ # want a single trunk port that terminates in different VXLAN interface depending on the VLAN) ++ # ++ # Addendum: A little explanation how "Single VXLAN Device" works in kernel: ++ # In the beginning, a VXLAN interface could only have a single VNI assigned. You had to create one ++ # VXLAN device per VNI, which didn't scale. Therefore, the following flags were added: ++ # ++ # 1. link add dev type vxlan external ++ # This flag is what makes a VXLAN interface a "Single VXLAN Device"! ++ # The "external" flag is very oddly and cryptically named. While technically the naming is correct, as it ++ # indicates "whether an external control plane (e.g. ip route encap) or the internal FDB should be used" ++ # it doesn't really help you as a user. ++ # It was added in kernel commit ee122c79d4227f6ec642157834b6a90fcffa4382 ("vxlan: Flow based tunneling") ++ # and is called VXLAN_F_COLLECT_METADATA ++ # What this flag essentially does it that a VXLAN interface with "external" flag ++ # **will receive traffic for all VNIs** on the entire system, and there can be only ONE of them (unless ++ # you add the "vnifilter" flag!) ++ # With this flag active, you must do 'bridge vlan add dev vid tunnel_info id '! ++ # ++ # 2. link add dev type vxlan vnifilter ++ # As mentioned above, at some point it was recognized that there may be the need ++ # to have multiple "Single VXLAN Devices". ++ # Therefore in kernel commit f9c4bb0b245cee35ef66f75bf409c9573d934cf9 ++ # ("vxlan: vni filtering support on collect metadata device") the possibility ++ # to have multiple SVD's was added, using the "vnifilter" flag (kernel VXLAN_F_VNIFILTER) ++ # This flag limits which VNIs are received on a "Single VXLAN Device", ultimately ++ # allowing you to have multiple "Single VXLAN Devices" on the same system... ++ # and even on the same bridge! ++ # With this flag active, you must do 'bridge vni add dev vni ' ++ # yes, even though this uses the bridge command, this is not really related to bridges ++ # at all and is the name of a VXLAN interface! ++ ++ single_vxlan_device_ifaceobjs = [] + + try: + brports_ifla_info_slave_data = dict() +@@ -2471,7 +2515,7 @@ class bridge(Bridge, moduleBase): + # + + if brport_ifaceobj.link_privflags & ifaceLinkPrivFlags.SINGLE_VXLAN: +- single_vxlan_device_ifaceobj = brport_ifaceobj ++ single_vxlan_device_ifaceobjs.append(brport_ifaceobj) + brport_vlan_tunnel_cached_value = self.cache.get_link_info_slave_data_attribute( + brport_name, + Link.IFLA_BRPORT_VLAN_TUNNEL +@@ -2501,7 +2545,11 @@ class bridge(Bridge, moduleBase): + except Exception as e: + self.log_error(str(e), ifaceobj) + +- if single_vxlan_device_ifaceobj: ++ # As explained at the top of the function, we have have multiple SVD's enslaved to our bridge ++ # If we don't handle them all here, we will have the scenario where only the FIRST enslaved ++ # VXLAN interface gets the tunnel_info applied, and the other ones don't... Leading to the ++ # scenario that the network config is only correctly applied after another ifreload... ++ for single_vxlan_device_ifaceobj in single_vxlan_device_ifaceobjs: + self.apply_bridge_port_vlan_vni_map(single_vxlan_device_ifaceobj) + + @staticmethod diff --git a/debian/patches/series b/debian/patches/series index 1dc2fc6..a059c38 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -19,3 +19,4 @@ pve/0015-revert-addons-bond-warn-if-sub-interface-is-detected-on-bond-slave.patc pve/0016-nlcache-fix-missing-nodad-option-in-addr_add_dry_run.patch pve/0017-nlcache-add-missing-link_set_mtu_dry_run-method.patch pve/0018-iproute2-fix-bridge_link_update_vni_filter-for-dry-run.patch +pve/0019-bridge-fix-multiple-single-vxlan-Devices-in-bridge.patch -- 2.47.3