Re: [PATCH network] sdn: vxlan: always set local tunnel IP

["Lukas Sichert" <l.sichert@proxmox.com>]

On 2026-07-02 16:33, Gabriel Goller <g.goller@proxmox.com> wrote:

> Frr 10.6 changed the evpn advertise-all-vni handling and no longer
> falls back to the BGP router-id to derive the local vtep address for
> vxlan interfaces without an explicit local tunnel IP.
>
> This breaks setups where an evpn controller is used together with a
> vxlan zone to get plain L2VNIs. In that setup, the vxlan zone creates
> the linux vxlan devices, while the evpn controller advertises them
> via frr's advertise-all-vni. Without a local vxlan tunnel IP on the
> interface, frr 10.6 cannot reliably determine the local vtep address and
> the VNI is not advertised/handled correctly.
>
> Explicitly emit the ifupdown2 `vxlan-local-tunnelip` stanza for vxlan
> zones, using the local peer/fabric underlay address that is already
> determined while generating the zone configuration. Fail generation if
> no local tunnel IP can be determined, since generating such an interface
> would result in a broken evpn/vxlan setup with current frr.
>
> evpn zones already emit `vxlan-local-tunnelip` for their vxlan devices
> when the local vtep address is known.
>
> Fixes: #7766.
> Signed-off-by: Gabriel Goller <g.goller@proxmox.com>

I reproduced the issue on a three-node cluster using an EVPN controller
together with a plain VXLAN zone and L2 VNI 10600.

With FRR 10.4.1-1+pve1 and no vxlan-local-tunnelip on the generated
VXLAN interface, the VNI was detected and advertised:

 Number of L2 VNIs: 1

 * 10600 L2 172.16.0.100:2 65010:10600 65010:10600 default

After upgrading the same nodes to FRR 10.6.1-1+pve2, while keeping the
same SDN and interface configuration, the kernel VXLAN interface was
still present and `show evpn vni` listed VNI 10600, but:

 show bgp l2vpn evpn vni

reported:

 Number of L2 VNIs: 0

After applying this patch and regenerating the SDN configuration, the
VNI was detected and advertised again.

I think a corresponding fix has meanwhile been merged upstream in FRR[1],
so using an FRR 10.6 package containing that fix may be preferable in
the longer term. Nevertheless, this patch fixes the issue with the
currently packaged FRR version.

Tested-by: Lukas Sichert <l.sichert@proxmox.com>
[1] https://github.com/FRRouting/frr/pull/22555