From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 424C81FF13C for ; Thu, 11 Jun 2026 10:11:53 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D2ABB32372; Thu, 11 Jun 2026 10:11:50 +0200 (CEST) Content-Type: text/plain; charset=UTF-8 Date: Thu, 11 Jun 2026 10:11:45 +0200 Message-Id: Subject: Re: [PATCH network v2 1/5] sdn: evpn: enable force_forwarding for ipv6 forwarding to subnets From: "Lukas Sichert" To: "Gabriel Goller" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable References: <20260603142921.91174-1-l.sichert@proxmox.com> <20260603142921.91174-2-l.sichert@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1781165457694 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.280 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com,evpnplugin.pm] Message-ID-Hash: XTKVZD3Z4TT6DBGHWFM6KLKFRVOCGP3M X-Message-ID-Hash: XTKVZD3Z4TT6DBGHWFM6KLKFRVOCGP3M X-MailFrom: l.sichert@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Thanks for looking into it. I will send a v3. Some Comments are inline. On 2026-06-08 11:46, Gabriel Goller wrote: > On 03.06.2026 16:29, Lukas Sichert wrote: >> EVPN zones can route IPv6 subnet traffic through a VNet and an outgoing >> interface. Until now, this depended on global IPv6 forwarding state, >> which also changes Router Advertisement handling for the whole host. >>=20 >> Use the per-interface 'force_forwarding' setting instead. For IPv6 >> subnets that need forwarding, generate post-up/post-down commands for >> both the VNet interface and the outgoing interface. Track interfaces >> that already received 'force_forwarding' commands to avoid duplicates >> when multiple subnets share the same outgoing path. Update the expected >> SDN interface output in the zone tests accordingly. >>=20 >> Signed-off-by: Lukas Sichert >> --- >> src/PVE/Network/SDN/Zones/EvpnPlugin.pm | 20 +++++++++++++++---- >> .../expected_sdn_interfaces | 4 ++++ >> .../exitnode_snat/expected_sdn_interfaces | 4 ++++ >> .../exitnodenullroute/expected_sdn_interfaces | 4 ++++ >> .../evpn/ipv4ipv6/expected_sdn_interfaces | 4 ++++ >> .../zones/evpn/ipv6/expected_sdn_interfaces | 4 ++++ >> .../evpn/ipv6underlay/expected_sdn_interfaces | 4 ++++ >> 7 files changed, 40 insertions(+), 4 deletions(-) >>=20 >> diff --git a/src/PVE/Network/SDN/Zones/EvpnPlugin.pm b/src/PVE/Network/S= DN/Zones/EvpnPlugin.pm >> index dfbd7e9..7622457 100644 >> --- a/src/PVE/Network/SDN/Zones/EvpnPlugin.pm >> +++ b/src/PVE/Network/SDN/Zones/EvpnPlugin.pm >> @@ -238,11 +238,13 @@ sub generate_sdn_config { >> my $ipv6 =3D undef; >> my $enable_forward_v4 =3D undef; >> my $enable_forward_v6 =3D undef; >> + my $force_forward_enabled =3D {}; >> my $subnets =3D PVE::Network::SDN::Vnets::get_subnets($vnetid, 1); >> foreach my $subnetid (sort keys %{$subnets}) { >> my $subnet =3D $subnets->{$subnetid}; >> my $cidr =3D $subnet->{cidr}; >> my $mask =3D $subnet->{mask}; >> + my $vnet =3D $subnet->{vnet}; >> =20 >> my $gateway =3D $subnet->{gateway}; >> if ($gateway) { >> @@ -266,11 +268,21 @@ sub generate_sdn_config { >> $enable_forward_v4 =3D 1 if $gateway; >> } >> =20 >> - if ($subnet->{snat}) { >> + #find outgoing interface >> + my ($outip, $outiface) =3D >> + PVE::Network::SDN::Zones::Plugin::get_local_route_ip($check= routeip); > > Hmm this is now outside the snat branch, so we will run `ip route get 8.8= .8.8` > for subnets without a gateway and with snat enabled, which will always fa= il. > > Could it be that without gateway or snat there isn't an outgoing interfac= e and > thus no need to set force_forwarding? The 'get_local_route_ip' does not depend on the zone. '$checkrouteip' is only the IPv4/IPv6 address of google to resolve the outgoing interface. So as long as there is an interface, that has an ip address of the same version as the google address and that has internet access, it won't fail. If it fails, then the if clause below would prevent any 'force_forwarding' from being set, but actually it throws an error and aborts the loop. There is a patch already to make it fail gracefully and not abort the loop iterating through the subnets.[1] > >> + >> + if ($outiface && $enable_forward_v6 && !($force_forward_enabled= ->{$outiface})) { > > Will this enable force_forwarding on a ipv4 subnet if there is a ipv6 sub= net > that sets $enable_forward_v6 followed by a ipv4 subnet? I think we need t= o reset > the $enable_forward_v6 variable before the loop? Yes, also, if the '$enable_forward_v6' is set once, then for all subsequent nets, it remains set. Thanks for pointing it out. > >> + push @iface_config, >> + "post-up echo 1 > /proc/sys/net/ipv6/conf/$outiface/for= ce_forwarding"; >> + push @iface_config, >> + "post-down echo 0 > /proc/sys/net/ipv6/conf/$outiface/f= orce_forwarding"; >> + push @iface_config, "post-up echo 1 > /proc/sys/net/ipv6/co= nf/$vnet/force_forwarding"; >> + push @iface_config, "post-down echo 0 > /proc/sys/net/ipv6/= conf/$vnet/force_forwarding"; > > Could it happen here that with the post-down we can bring down a shared > interface? e.g. if a zone/vnet use the same vmbr0 bridge and then deletin= g one > removes the force_forwarding on the other one? > > Not sure if this can happen. If yes, we could either just remove the post= -down > or add some complicated ref-couting (not a fan of that). But wouldn't this require manually executing 'ifdown '? Because for a normal SDN-Apply the whole configuration would be regenerated and the 'post-down' commands removed. [1] https://lore.proxmox.com/all/20260601124228.77298-1-l.sichert@proxmox.c= om/