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 5C9A01FF0E4 for ; Tue, 14 Jul 2026 13:47:41 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 979C7213E9; Tue, 14 Jul 2026 13:47:40 +0200 (CEST) Date: Tue, 14 Jul 2026 13:47:03 +0200 From: Gabriel Goller To: Lukas Sichert Subject: Re: [PATCH network] sdn: vxlan: always set local tunnel IP Message-ID: Mail-Followup-To: Lukas Sichert , pve-devel@lists.proxmox.com References: <20260702143349.252142-1-g.goller@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20260504 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784029607177 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.458 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_LOW -0.7 Sender listed at https://www.dnswl.org/, low 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: YYZWU4BLYMTRE2OPRN4SAGQRIYB7YRPM X-Message-ID-Hash: YYZWU4BLYMTRE2OPRN4SAGQRIYB7YRPM X-MailFrom: g.goller@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 CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 14.07.2026 12:44, Lukas Sichert wrote: > On 2026-07-02 16:33, Gabriel Goller wrote: > > > Frr 10.6 changed the evpn advertise-all-vni handling and no longer > > falls back to the BGP router-id to derive the local vtep address for > > vxlan interfaces without an explicit local tunnel IP. > > > > This breaks setups where an evpn controller is used together with a > > vxlan zone to get plain L2VNIs. In that setup, the vxlan zone creates > > the linux vxlan devices, while the evpn controller advertises them > > via frr's advertise-all-vni. Without a local vxlan tunnel IP on the > > interface, frr 10.6 cannot reliably determine the local vtep address and > > the VNI is not advertised/handled correctly. > > > > Explicitly emit the ifupdown2 `vxlan-local-tunnelip` stanza for vxlan > > zones, using the local peer/fabric underlay address that is already > > determined while generating the zone configuration. Fail generation if > > no local tunnel IP can be determined, since generating such an interface > > would result in a broken evpn/vxlan setup with current frr. > > > > evpn zones already emit `vxlan-local-tunnelip` for their vxlan devices > > when the local vtep address is known. > > > > Fixes: #7766. > > Signed-off-by: Gabriel Goller > > I reproduced the issue on a three-node cluster using an EVPN controller > together with a plain VXLAN zone and L2 VNI 10600. > > With FRR 10.4.1-1+pve1 and no vxlan-local-tunnelip on the generated > VXLAN interface, the VNI was detected and advertised: > > Number of L2 VNIs: 1 > > * 10600 L2 172.16.0.100:2 65010:10600 65010:10600 default > > After upgrading the same nodes to FRR 10.6.1-1+pve2, while keeping the > same SDN and interface configuration, the kernel VXLAN interface was > still present and `show evpn vni` listed VNI 10600, but: > > show bgp l2vpn evpn vni > > reported: > > Number of L2 VNIs: 0 > > After applying this patch and regenerating the SDN configuration, the > VNI was detected and advertised again. > > I think a corresponding fix has meanwhile been merged upstream in FRR[1], > so using an FRR 10.6 package containing that fix may be preferable in > the longer term. Nevertheless, this patch fixes the issue with the > currently packaged FRR version. > > Tested-by: Lukas Sichert > [1] https://github.com/FRRouting/frr/pull/22555 Thanks for testing! Backport for my PR is here: https://lore.proxmox.com/pve-devel/20260714111858.232230-1-g.goller@proxmox.com/ The frr backport can definitely be merged. I would also recommend merging this patch, since vxlan interfaces without a local IP address do make sense in some scenarios, but they are (1) unusual and (2) not really needed for our use case here. What we maybe need to test as well (for this patch): * Receiving on multiple local addresses * Let routing/policy choose the source address (ip route src) These are both only possible with custom setups I think.