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 6202D1FF0B3 for ; Wed, 09 Sep 2026 11:23:06 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 5D2F7215E4; Wed, 09 Sep 2026 11:23:04 +0200 (CEST) Date: Wed, 9 Sep 2026 11:22:59 +0200 From: Gabriel Goller To: Stefan Hanreich Subject: Re: [PATCH] sdn: evpn: allow vlan-aware vnets Message-ID: Mail-Followup-To: Stefan Hanreich , Thomas Glanzmann , pve-devel@lists.proxmox.com References: <1ddca9b8-410e-42c5-9b36-5c84b8e8aa0f@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1ddca9b8-410e-42c5-9b36-5c84b8e8aa0f@proxmox.com> User-Agent: NeoMutt/20260504 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788945770887 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.162 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: PXAZ6IMTWIQ4YWBGV5IRKCQ4KQF655PV X-Message-ID-Hash: PXAZ6IMTWIQ4YWBGV5IRKCQ4KQF655PV 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: Thomas Glanzmann , 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 09.09.2026 10:40, Stefan Hanreich wrote: > > > 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? Yes, this should be fixed with https://github.com/FRRouting/frr/pull/22555. Note that `show evpn vni x` shows the zebra vtep, and zebra can't find a vtep as there is no vxlan-local-tunnelip set on the interface. bgpd will fallback to the router-ip, so `show bgp l2vpn evpn route` should show routes with the correct derived vtep ip. The ifupdown2 warning is only printed on the syntax-check, which gets executed when using e.g. `ifreload -s`. We don't do that anywhere AFAICS. Maybe we should patch this warning out as it's technically false. No vxlan-local-tunnelip does make sense when e.g. using source routing (ip src) or multiple local addresses (migration). > [...] > > > 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/ >