From: Hannes Laimer <h.laimer@proxmox.com>
To: Gabriel Goller <g.goller@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [PATCH pve-network] sdn: zones: vxlan: restore the flood entries after an FRR reload
Date: Mon, 5 Oct 2026 15:01:44 +0200 [thread overview]
Message-ID: <c06d9d92-ac66-4ee5-833c-c3675485c309@proxmox.com> (raw)
In-Reply-To: <asOW5HUG29uDKilc@luna.proxmox.com>
On 2026-10-05 14:31, Gabriel Goller wrote:
> On 29.09.2026 11:28, Hannes Laimer wrote:
>> With advertise-all-vni, which an EVPN controller sets even without an
>> EVPN zone, FRR treats every vxlan device on a node as an EVPN VNI.
>> That includes the devices of a VXLAN zone, for which the other nodes
>> running FRR become remote VTEPs.
>>
>> When the controller is removed, FRR drops its VNIs and deletes the
>> flood entries of their remote VTEPs. The kernel identifies such an
>> entry by its address and not by who added it, so the zone's static
>> flood entries to those nodes are deleted. The zone can no longer
>> flood, so nothing resolves across nodes, and no reload repairs it,
>> since ifupdown2 re-applies the peer list only when the configured list
>> changed.
>>
>> Re-append the entries after every FRR apply. The kernel treats an
>> existing remote as a no-op, so the entries are simply added where
>> missing.
>>
>> Signed-off-by: Hannes Laimer <h.laimer@proxmox.com>
>> ---
>> src/PVE/Network/SDN.pm | 7 ++++++-
>> src/PVE/Network/SDN/Zones.pm | 18 ++++++++++++++++++
>> 2 files changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/PVE/Network/SDN.pm b/src/PVE/Network/SDN.pm
>> index 33a3cf3..42af00d 100644
>> --- a/src/PVE/Network/SDN.pm
>> +++ b/src/PVE/Network/SDN.pm
>> @@ -492,7 +492,12 @@ sub generate_frr_config {
>> my $raw_config = PVE::Network::SDN::generate_frr_raw_config($running_config, $fabric_config);
>> PVE::Network::SDN::Frr::write_raw_config($raw_config);
>>
>> - PVE::Network::SDN::Frr::apply($needs_restart) if $apply;
>> + return if !$apply;
>> +
>> + PVE::Network::SDN::Frr::apply($needs_restart);
>> +
>> + # zebra removes a VXLAN zone's static flood entries with the VTEPs it withdraws
>> + PVE::Network::SDN::Zones::restore_vxlan_flood_entries();
>
> Hmm so this is tricky, on reload bgpd tells zebra to remove these changes
> and zebra enqueues this to the dplane, so this is asynchronous in many
> ways. So we can't guarantee that the entries have been removed when running
> restore_vxlan_flood_entries().
>
yes, this is unfortunately not something we can guarantee. restart
happens already at the end of FRR::apply, we could force a `reload` of
there is a removed evpn controller and an existing vxlan zone. I'm not
sure there is a difference for this here tough..
> Not sure what we could do here.
>
> Three options that came to my mind where:
> 1) sleep(5)
not sure what kind of timeframes are realistic here, since we can't
guarantee anything anyway, something like 1s is probably enough. but in
my (limited) testing i also couldn't hit this without any sleep
> 2) `bridge monitor fdb` before running the frr reload/restart and then check if the entries have been removed (kind of overkill)
we still wouldn't know how long to wait..
> 3) force a frr restart (not 100% sure if this works)
>
ideally we could just tell frr 'hands off these VNIs..', but we can't,
and given `advertise-all-vni` that might also be weird/wrong to begin
with
>> }
>>
>> sub generate_dhcp_config {
>> diff --git a/src/PVE/Network/SDN/Zones.pm b/src/PVE/Network/SDN/Zones.pm
>> index f668303..2c3c69c 100644
>> --- a/src/PVE/Network/SDN/Zones.pm
>> +++ b/src/PVE/Network/SDN/Zones.pm
>> @@ -178,6 +178,24 @@ sub generate_etc_network_config {
>> return $raw_network_config;
>> }
>>
>> +sub restore_vxlan_flood_entries {
>> + my $raw_config = eval { PVE::Tools::file_get_contents($local_network_sdn_file) };
>> + return if !defined($raw_config);
>
> Maybe an error here would be nice instead of a silent return. Although this
> probably can't happen anyway...
>
yeah, not really an error imho.. but a warning should be fine,
because the caller assumed there is a config file
thanks for taking a look! :)
>> +
>> + my $iface;
>> + for my $line (split(/\n/, $raw_config)) {
>> + if ($line =~ m/^iface (\S+)$/) {
>> + $iface = $1;
>> + } elsif ($line =~ m/^\s+vxlan_remoteip (\S+)$/) {
>> + my $address = $1;
>> + my $cmd =
>> + ['bridge', 'fdb', 'append', '00:00:00:00:00:00', 'dev', $iface, 'dst', $address];
>> + eval { run_command($cmd) };
>> + warn "$iface: restoring the flood entry to $address failed: $@" if $@;
>> + }
>> + }
>> +}
>> +
>> sub read_etc_network_config_version {
>> my $versionstr = PVE::Tools::file_read_firstline($local_network_sdn_file);
>>
>> --
>> 2.47.3
next prev parent reply other threads:[~2026-10-05 13:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 9:28 [PATCH pve-network] sdn: zones: vxlan: restore the flood entries after an FRR reload Hannes Laimer
2026-10-05 12:31 ` Gabriel Goller
2026-10-05 13:01 ` Hannes Laimer [this message]
2026-10-05 13:13 ` Gabriel Goller
2026-10-05 13:32 ` Hannes Laimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c06d9d92-ac66-4ee5-833c-c3675485c309@proxmox.com \
--to=h.laimer@proxmox.com \
--cc=g.goller@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox