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

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

[Gabriel Goller]

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>
---
 src/PVE/Network/SDN/Zones/VxlanPlugin.pm                   | 4 ++++
 src/test/zones/vxlan/basic/expected_sdn_interfaces         | 1 +
 src/test/zones/vxlan/ipv6/expected_sdn_interfaces          | 1 +
 src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces | 1 +
 src/test/zones/vxlan/vxlanport/expected_sdn_interfaces     | 1 +
 5 files changed, 8 insertions(+)

diff --git a/src/PVE/Network/SDN/Zones/VxlanPlugin.pm b/src/PVE/Network/SDN/Zones/VxlanPlugin.pm
index a40826153d9c..b1bd56db6ea9 100644
--- a/src/PVE/Network/SDN/Zones/VxlanPlugin.pm
+++ b/src/PVE/Network/SDN/Zones/VxlanPlugin.pm
@@ -117,6 +117,9 @@ sub generate_sdn_config {
         die "neither peers nor fabric configured for VXLAN zone $plugin_config->{id}";
     }
 
+    die "could not determine local tunnel IP for VXLAN zone $zoneid"
+        if !$ifaceip;
+
     my $mtu = 1450;
     if ($iface) {
         $mtu = $interfaces_config->{$iface}->{mtu} - 50 if $interfaces_config->{$iface}->{mtu};
@@ -126,6 +129,7 @@ sub generate_sdn_config {
     #vxlan interface
     my @iface_config = ();
     push @iface_config, "vxlan-id $tag";
+    push @iface_config, "vxlan-local-tunnelip $ifaceip";
 
     for my $address (sort @peers) {
         next if $address eq $ifaceip;
diff --git a/src/test/zones/vxlan/basic/expected_sdn_interfaces b/src/test/zones/vxlan/basic/expected_sdn_interfaces
index 7b73c3e3ca60..ed6869dfa9e6 100644
--- a/src/test/zones/vxlan/basic/expected_sdn_interfaces
+++ b/src/test/zones/vxlan/basic/expected_sdn_interfaces
@@ -10,6 +10,7 @@ iface myvnet
 auto vxlan_myvnet
 iface vxlan_myvnet
 	vxlan-id 100
+	vxlan-local-tunnelip 192.168.0.1
 	vxlan_remoteip 192.168.0.2
 	vxlan_remoteip 192.168.0.3
 	mtu 1450
diff --git a/src/test/zones/vxlan/ipv6/expected_sdn_interfaces b/src/test/zones/vxlan/ipv6/expected_sdn_interfaces
index 032ab991826c..14354f61f923 100644
--- a/src/test/zones/vxlan/ipv6/expected_sdn_interfaces
+++ b/src/test/zones/vxlan/ipv6/expected_sdn_interfaces
@@ -10,6 +10,7 @@ iface myvnet
 auto vxlan_myvnet
 iface vxlan_myvnet
 	vxlan-id 100
+	vxlan-local-tunnelip 2a08:2200:100:1::10
 	vxlan_remoteip 2a08:2200:100:1::11
 	vxlan_remoteip 2a08:2200:100:1::12
 	mtu 1450
diff --git a/src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces b/src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces
index 55cdf9cb8887..e6331d2e3807 100644
--- a/src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces
+++ b/src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces
@@ -12,6 +12,7 @@ iface myvnet
 auto vxlan_myvnet
 iface vxlan_myvnet
 	vxlan-id 100
+	vxlan-local-tunnelip 192.168.0.1
 	vxlan_remoteip 192.168.0.2
 	vxlan_remoteip 192.168.0.3
 	mtu 1450
diff --git a/src/test/zones/vxlan/vxlanport/expected_sdn_interfaces b/src/test/zones/vxlan/vxlanport/expected_sdn_interfaces
index 572550a438e7..a3147b66a9c1 100644
--- a/src/test/zones/vxlan/vxlanport/expected_sdn_interfaces
+++ b/src/test/zones/vxlan/vxlanport/expected_sdn_interfaces
@@ -10,6 +10,7 @@ iface myvnet
 auto vxlan_myvnet
 iface vxlan_myvnet
 	vxlan-id 100
+	vxlan-local-tunnelip 192.168.0.1
 	vxlan_remoteip 192.168.0.2
 	vxlan_remoteip 192.168.0.3
 	vxlan-port 6000
-- 
2.47.3

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

[Gabriel Goller]

Hmm maybe we could also fix this in FRR as this was not a 100% intended change.
I'll think about it and talk with Stefan when he's back.

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

[Gabriel Goller]

On 02.07.2026 16:37, Gabriel Goller wrote:
> Hmm maybe we could also fix this in FRR as this was not a 100% intended change.
> I'll think about it and talk with Stefan when he's back.

PR: https://github.com/FRRouting/frr/pull/22555

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

[Gabriel Goller]

On 02.07.2026 16:33, Gabriel Goller 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>
> ---
>  src/PVE/Network/SDN/Zones/VxlanPlugin.pm                   | 4 ++++
>  src/test/zones/vxlan/basic/expected_sdn_interfaces         | 1 +
>  src/test/zones/vxlan/ipv6/expected_sdn_interfaces          | 1 +
>  src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces | 1 +
>  src/test/zones/vxlan/vxlanport/expected_sdn_interfaces     | 1 +
>  5 files changed, 8 insertions(+)
> 
> diff --git a/src/PVE/Network/SDN/Zones/VxlanPlugin.pm b/src/PVE/Network/SDN/Zones/VxlanPlugin.pm
> index a40826153d9c..b1bd56db6ea9 100644
> --- a/src/PVE/Network/SDN/Zones/VxlanPlugin.pm
> +++ b/src/PVE/Network/SDN/Zones/VxlanPlugin.pm
> @@ -117,6 +117,9 @@ sub generate_sdn_config {
>          die "neither peers nor fabric configured for VXLAN zone $plugin_config->{id}";
>      }
>  
> +    die "could not determine local tunnel IP for VXLAN zone $zoneid"
> +        if !$ifaceip;
> +
>      my $mtu = 1450;
>      if ($iface) {
>          $mtu = $interfaces_config->{$iface}->{mtu} - 50 if $interfaces_config->{$iface}->{mtu};
> @@ -126,6 +129,7 @@ sub generate_sdn_config {
>      #vxlan interface
>      my @iface_config = ();
>      push @iface_config, "vxlan-id $tag";
> +    push @iface_config, "vxlan-local-tunnelip $ifaceip";
>  
>      for my $address (sort @peers) {
>          next if $address eq $ifaceip;

Just for completeness sake:
If we do not have the `$ifaceip` for some reason, the local ip will be inserted
into the vxlan-remote-ip list, which breaks the vxlan setup completely. So we
should be safe to assume here that any working setup has an `$ifaceip`.

Still we can either backport the frr pr, merge this, or pull in both patches.

> diff --git a/src/test/zones/vxlan/basic/expected_sdn_interfaces b/src/test/zones/vxlan/basic/expected_sdn_interfaces
> index 7b73c3e3ca60..ed6869dfa9e6 100644
> --- a/src/test/zones/vxlan/basic/expected_sdn_interfaces
> +++ b/src/test/zones/vxlan/basic/expected_sdn_interfaces
> @@ -10,6 +10,7 @@ iface myvnet
>  auto vxlan_myvnet
>  iface vxlan_myvnet
>  	vxlan-id 100
> +	vxlan-local-tunnelip 192.168.0.1
>  	vxlan_remoteip 192.168.0.2
>  	vxlan_remoteip 192.168.0.3
>  	mtu 1450
> diff --git a/src/test/zones/vxlan/ipv6/expected_sdn_interfaces b/src/test/zones/vxlan/ipv6/expected_sdn_interfaces
> index 032ab991826c..14354f61f923 100644
> --- a/src/test/zones/vxlan/ipv6/expected_sdn_interfaces
> +++ b/src/test/zones/vxlan/ipv6/expected_sdn_interfaces
> @@ -10,6 +10,7 @@ iface myvnet
>  auto vxlan_myvnet
>  iface vxlan_myvnet
>  	vxlan-id 100
> +	vxlan-local-tunnelip 2a08:2200:100:1::10
>  	vxlan_remoteip 2a08:2200:100:1::11
>  	vxlan_remoteip 2a08:2200:100:1::12
>  	mtu 1450
> diff --git a/src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces b/src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces
> index 55cdf9cb8887..e6331d2e3807 100644
> --- a/src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces
> +++ b/src/test/zones/vxlan/vlanawarevnet/expected_sdn_interfaces
> @@ -12,6 +12,7 @@ iface myvnet
>  auto vxlan_myvnet
>  iface vxlan_myvnet
>  	vxlan-id 100
> +	vxlan-local-tunnelip 192.168.0.1
>  	vxlan_remoteip 192.168.0.2
>  	vxlan_remoteip 192.168.0.3
>  	mtu 1450
> diff --git a/src/test/zones/vxlan/vxlanport/expected_sdn_interfaces b/src/test/zones/vxlan/vxlanport/expected_sdn_interfaces
> index 572550a438e7..a3147b66a9c1 100644
> --- a/src/test/zones/vxlan/vxlanport/expected_sdn_interfaces
> +++ b/src/test/zones/vxlan/vxlanport/expected_sdn_interfaces
> @@ -10,6 +10,7 @@ iface myvnet
>  auto vxlan_myvnet
>  iface vxlan_myvnet
>  	vxlan-id 100
> +	vxlan-local-tunnelip 192.168.0.1
>  	vxlan_remoteip 192.168.0.2
>  	vxlan_remoteip 192.168.0.3
>  	vxlan-port 6000
> -- 
> 2.47.3
> 
> 
> 
> 
> 

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

[Lukas Sichert]

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

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

[Gabriel Goller]

On 14.07.2026 12:44, Lukas Sichert wrote:
> 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

Thanks for testing!

Backport for my PR is here:
https://lore.proxmox.com/pve-devel/20260714111858.232230-1-g.goller@proxmox.com/

The frr backport can definitely be merged. I would also recommend merging this patch, since vxlan
interfaces without a local IP address do make sense in some scenarios, but they are (1) unusual and
(2) not really needed for our use case here.

What we maybe need to test as well (for this patch):
 * Receiving on multiple local addresses
 * Let routing/policy choose the source address (ip route src)

These are both only possible with custom setups I think.

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

[Lukas Sichert]

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 tested the FRR backport [1] together with the PVE SDN patch.

The custom datapath tests used two nodes:

  pve1-cluster: vmbr0 with 172.16.0.100/24 and 172.16.0.200/24,
                ctestvx VNI 4243 with 10.0.44.1/24
  pve2-cluster: vmbr0 with 172.16.0.101/24,
                ctestvx VNI 4243 with 10.0.44.2/24

1. No patch applied

With the affected FRR package and the generated VXLAN interface not having
an explicit `vxlan-local-tunnelip`, the kernel VXLAN interface existed:

  vxlan id 10600 srcport 0 0 dstport 4789

but FRR did not detect/advertise the L2 VNI:

  Number of L2 VNIs: 0

In the custom no-local VXLAN setup, traffic sent to both tested local
underlay addresses was decapsulated successfully. When the route towards
the remote underlay selected `src 172.16.0.200`, outgoing VXLAN packets
also used `172.16.0.200` as outer source.

2. Only the PVE SDN patch applied

After applying the PVE SDN patch and regenerating the SDN configuration,
the generated VXLAN interface contained an explicit local tunnel IP:

  vxlan-local-tunnelip 172.16.0.100

After reloading the network configuration, the kernel VXLAN interface also
had the corresponding local address:

  vxlan id 10600 local 172.16.0.100 srcport 0 0 dstport 4789

After restarting FRR, the VNI was detected and advertised again with
`172.16.0.100` as local VTEP address:

  Number of L2 VNIs: 1
  * 10600 L2 172.16.0.100:2 65010:10600 65010:10600 default

Compared to the no-local custom setup, receiving traffic sent to either
tested local underlay address still worked. The difference was the outgoing
source address: with `local 172.16.0.100` configured on the VXLAN device,
outgoing VXLAN packets used `172.16.0.100` as outer source even when the
route lookup selected `src 172.16.0.200`.

In the custom test this resulted in asymmetric outer VXLAN traffic: the
echo request from the node with the explicit local tunnel IP used
`172.16.0.100` as outer source, while the remote node sent the echo reply
back to `172.16.0.200`, because its FDB entry pointed there. The overlay
ping still succeeded.

3. PVE SDN patch and FRR backport applied

With both patches applied, the generated VXLAN interface still contained
the explicit `vxlan-local-tunnelip`, and FRR continued to detect and
advertise the VNI with `172.16.0.100` as local VTEP address:

  vxlan id 10600 local 172.16.0.100 srcport 0 0 dstport 4789
  Number of L2 VNIs: 1
  * 10600 L2 172.16.0.100:2 65010:10600 65010:10600 default

The custom two-node setup showed the same datapath behavior as in case 2
when an explicit local tunnel IP was configured: traffic sent to both
tested local underlay addresses was decapsulated successfully. For outgoing
traffic, the configured VXLAN local tunnel IP was used as outer source,
even when the route lookup selected a different `src` address. The replies
were sent to the address configured in the remote FDB entry and were also
decapsulated successfully.

[1] https://lore.proxmox.com/all/20260714111858.232230-1-g.goller@proxmox.com/