Re: [PATCH] sdn: evpn: allow vlan-aware vnets

[Gabriel Goller <g.goller@proxmox.com>]

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/
>