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/[email protected]/ >
