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 A94991FF0B3 for ; Wed, 09 Sep 2026 10:40:25 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id AC5A421599; Wed, 09 Sep 2026 10:40:22 +0200 (CEST) Message-ID: <1ddca9b8-410e-42c5-9b36-5c84b8e8aa0f@proxmox.com> Date: Wed, 9 Sep 2026 10:40:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] sdn: evpn: allow vlan-aware vnets To: Thomas Glanzmann References: Content-Language: en-US From: Stefan Hanreich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.666 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) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium 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: D456RQNV7WRK5ALUIOKOLLUTL3TQVAMC X-Message-ID-Hash: D456RQNV7WRK5ALUIOKOLLUTL3TQVAMC X-MailFrom: s.hanreich@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 9/8/26 10:56 PM, Thomas Glanzmann wrote: > Hello Stefan, > >> Does utilizing a VLAN-aware VXLAN zone with an EVPN controller and then >> attaching a route map to the EVPN controller work for your use case as >> well? > > Yes. I rebuilt my setup that way and it does everything the patch did, so > consider the patch withdrawn in favour of your approach - with one > packaging gap that has to be closed first, see below. > > I tested it against three foreign VTEP implementations. Versions: > > Proxmox PVE 9.2.11, libpve-network-perl 1.6.7 (stock, no patches), > libpve-rs-perl 0.15.3, frr 10.6.1-1+pve3, > ifupdown2 3.3.0-1+pmx12 VTEP 10.101.0.18 > MikroTik CRS304-4XG, RouterOS 7.25beta3 VTEP 172.31.0.4 > Cisco N9K-C9372TX, NX-OS 9.3(16) VTEP 172.31.0.7 > BIRD 3.3.2 (Debian bird3) VTEP 172.31.0.118 > [...] > So the answer to your question is yes, and I prefer your shape to mine: it > gets the L2 EVI without a VRF, and the filtering is explicit and visible in > the configuration instead of hardcoded in a plugin. Thanks for testing! I personally also prefer the solution with the explicit route map for that reason. [...] >> Do you see any other issues, particularly with your specific setup? > > Three, one of them a blocker. > > 1. Zones/VxlanPlugin.pm never emits vxlan-local-tunnelip. This is the one > thing that stops your proposal from working out of the box, and it fails > silently. generate_sdn_config computes $ifaceip via > find_local_ip_interface_peers() (or from the fabric node) and then never > uses it for the interface: [...] > > No type-3 is originated, no VTEP is learned, nothing forwards, and all > BGP sessions look perfectly healthy while this is the case. This does > not matter for a plain VXLAN zone, because static vxlan_remoteip > head-end replication works fine without a local tunnel IP - it bites > only the moment an EVPN controller is supposed to drive that zone, > which is precisely the setup you want to make official. I worked around > it with > > # /etc/network/interfaces.d/zz-vxlan-local-tunnelip > iface vxlan_e1 > vxlan-local-tunnelip 10.101.0.18 > > which ifupdown2 merges with the generated stanza and which survives > pvesh set /cluster/sdn. Immediately after adding it: Vlan: 1, > Local VTEP IP: 10.101.0.18, and all three remote VTEPs appear with > flood: HER. Adding the same push to VxlanPlugin.pm as EvpnPlugin.pm > already has would fix it; I am happy to send that as a patch if you > want it. That should have already been fixed in the FRR version used in your tests (10.6.1-1+pve3) [1] as that was a bug introduced in version 10.6. @Gabriel can you take a look? [...] > One smaller note: with a single EVPN controller > skip_route_target_filtering() returns true, so MAP_VTEP_OUT is a bare > permit 1 plus the call; with several controllers the generated > extcommunity match is added alongside the call, and I have not tested that > combination. > > So: tenable, yes, and I would rather have your version than mine. If the > vxlan-local-tunnelip line lands, the setup works with no patched Perl at > all, which I have now verified against NX-OS, RouterOS and BIRD at the > same time. Yes, with multiple EVPN controllers this would most likely break out of the box - since only Route Targets from EVPN zones / vnets are considered when generating the extcommunity list for the RT filter. It is possible to override this behavior with a custom route map as well, even if it is just a blank permit. This could be more ergonomic though since it is required to build the RT filter manually with Route Map entries... [1] https://lore.proxmox.com/pve-devel/20260714111858.232230-1-g.goller@proxmox.com/