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 626721FF0E4 for ; Tue, 14 Jul 2026 12:45:00 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id C7207213EA; Tue, 14 Jul 2026 12:44:59 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 14 Jul 2026 12:44:24 +0200 Message-Id: Subject: Re: [PATCH network] sdn: vxlan: always set local tunnel IP From: "Lukas Sichert" To: "Gabriel Goller" , References: <20260702143349.252142-1-g.goller@proxmox.com> In-Reply-To: <20260702143349.252142-1-g.goller@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784025848674 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.210 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: K7EHC4KG4O3GZXEQ5LBCLPC24C67WX3A X-Message-ID-Hash: K7EHC4KG4O3GZXEQ5LBCLPC24C67WX3A X-MailFrom: l.sichert@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: 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