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

[Stefan Hanreich <s.hanreich@proxmox.com>]

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/