From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id C5C2A1FF130 for ; Mon, 20 Jul 2026 18:51:55 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 20BCB214C3; Mon, 20 Jul 2026 18:51:55 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 20 Jul 2026 18:51:49 +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: 1784566284558 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.137 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: E6DTL46R5B3HZNJ7OXC4NP6FB2NKRREI X-Message-ID-Hash: E6DTL46R5B3HZNJ7OXC4NP6FB2NKRREI 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 tested the FRR backport [1] together with the PVE SDN patch. The custom datapath tests used two nodes: pve1-cluster: vmbr0 with 172.16.0.100/24 and 172.16.0.200/24, ctestvx VNI 4243 with 10.0.44.1/24 pve2-cluster: vmbr0 with 172.16.0.101/24, ctestvx VNI 4243 with 10.0.44.2/24 1. No patch applied With the affected FRR package and the generated VXLAN interface not having an explicit `vxlan-local-tunnelip`, the kernel VXLAN interface existed: vxlan id 10600 srcport 0 0 dstport 4789 but FRR did not detect/advertise the L2 VNI: Number of L2 VNIs: 0 In the custom no-local VXLAN setup, traffic sent to both tested local underlay addresses was decapsulated successfully. When the route towards the remote underlay selected `src 172.16.0.200`, outgoing VXLAN packets also used `172.16.0.200` as outer source. 2. Only the PVE SDN patch applied After applying the PVE SDN patch and regenerating the SDN configuration, the generated VXLAN interface contained an explicit local tunnel IP: vxlan-local-tunnelip 172.16.0.100 After reloading the network configuration, the kernel VXLAN interface also had the corresponding local address: vxlan id 10600 local 172.16.0.100 srcport 0 0 dstport 4789 After restarting FRR, the VNI was detected and advertised again with `172.16.0.100` as local VTEP address: Number of L2 VNIs: 1 * 10600 L2 172.16.0.100:2 65010:10600 65010:10600 default Compared to the no-local custom setup, receiving traffic sent to either tested local underlay address still worked. The difference was the outgoing source address: with `local 172.16.0.100` configured on the VXLAN device, outgoing VXLAN packets used `172.16.0.100` as outer source even when the route lookup selected `src 172.16.0.200`. In the custom test this resulted in asymmetric outer VXLAN traffic: the echo request from the node with the explicit local tunnel IP used `172.16.0.100` as outer source, while the remote node sent the echo reply back to `172.16.0.200`, because its FDB entry pointed there. The overlay ping still succeeded. 3. PVE SDN patch and FRR backport applied With both patches applied, the generated VXLAN interface still contained the explicit `vxlan-local-tunnelip`, and FRR continued to detect and advertise the VNI with `172.16.0.100` as local VTEP address: vxlan id 10600 local 172.16.0.100 srcport 0 0 dstport 4789 Number of L2 VNIs: 1 * 10600 L2 172.16.0.100:2 65010:10600 65010:10600 default The custom two-node setup showed the same datapath behavior as in case 2 when an explicit local tunnel IP was configured: traffic sent to both tested local underlay addresses was decapsulated successfully. For outgoing traffic, the configured VXLAN local tunnel IP was used as outer source, even when the route lookup selected a different `src` address. The replies were sent to the address configured in the remote FDB entry and were also decapsulated successfully. [1] https://lore.proxmox.com/all/20260714111858.232230-1-g.goller@proxmox.c= om/