From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Koral Ilgun <koralilgun@gmail.com>
Cc: netfilter-devel@vger.kernel.org, fw@strlen.de, phil@nwl.cc,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Koral Ilgun <koral.ilgun@adtran.com>
Subject: Re: [PATCH nf] netfilter: nft_flow_offload: do not offload multicast
Date: Thu, 29 Oct 2026 12:38:08 +0100 [thread overview]
Message-ID: <auMwIMerV-LQ-aNL@chamomile> (raw)
In-Reply-To: <20261028205938.662312-1-koralilgun@gmail.com>
On Wed, Oct 28, 2026 at 01:59:38PM -0700, Koral Ilgun wrote:
> From: Koral Ilgun <koral.ilgun@adtran.com>
>
> A flow holds one output per direction, which it resolves when it is
> added. The outputs of a multicast route change when listeners join
> or leave. So a multicast flow in the flowtable continues to send to
> the output that it resolved, also after the last listener left, and
> the counters of the multicast routing stop.
>
> IPv4 multicast stays out of the flowtable only because the reverse
> route lookup in nft_flow_route() refuses a multicast source address.
> The IPv6 route lookup has no such check, so IPv6 multicast that
> ip6mr forwards goes into the flowtable.
>
> Skip a multicast destination for both families, so that the result
> no longer depends on the route lookup.
Please, target nf-next for this patch.
I agree this is convenient, but you can still restrict to unicast
traffic via ruleset, so I don't think this qualify as a fix.
> Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression")
> Signed-off-by: Koral Ilgun <koral.ilgun@adtran.com>
> ---
> Tested on an arm64 router with Linux 6.18.54, with an inet flowtable
> that offloads forwarded flows, and IPv4 and IPv6 multicast routed from
> the WAN to one VLAN. Without this change, the IPv6 flow went into the
> flowtable after its first packets: the ip6mr vif counters showed 25 of
> 1,500 packets, and the receiver still got all 400 packets after its
> leave. With it, the vif counters showed 1,500 of 1,500, the flow stayed
> out of the flowtable, and the stream stopped about 2.5 s after the
> leave. IPv4 multicast stayed out of the flowtable before and after.
> Unicast IPv4 and IPv6 flows still went into the flowtable.
>
> net/netfilter/nft_flow_offload.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/net/netfilter/nft_flow_offload.c b/net/netfilter/nft_flow_offload.c
> index d3c5651dd699..1fc755e594b0 100644
> --- a/net/netfilter/nft_flow_offload.c
> +++ b/net/netfilter/nft_flow_offload.c
> @@ -10,6 +10,7 @@
> #include <linux/netfilter/nf_conntrack_common.h>
> #include <linux/netfilter/nf_tables.h>
> #include <net/ip.h>
> +#include <net/ipv6.h>
> #include <net/flow.h>
> #include <net/netfilter/nf_tables.h>
> #include <net/netfilter/nf_tables_core.h>
> @@ -35,6 +36,16 @@ static bool nft_flow_offload_skip(struct sk_buff *skb, int family)
> return true;
> }
>
> + /* A flow keeps the output it resolved at offload time, but the
> + * outputs of a multicast route change when listeners join or leave.
> + */
> + switch (family) {
> + case NFPROTO_IPV4:
> + return ipv4_is_multicast(ip_hdr(skb)->daddr);
> + case NFPROTO_IPV6:
> + return ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr);
> + }
> +
> return false;
> }
>
>
> base-commit: 734bef548a96e8774d6eef5dfa2026c6edc4e80b
> --
> 2.43.0
>
prev parent reply other threads:[~2026-10-29 11:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 20:59 [PATCH nf] netfilter: nft_flow_offload: do not offload multicast Koral Ilgun
2026-10-29 11:30 ` Fernando Fernandez Mancera
2026-10-29 11:38 ` Pablo Neira Ayuso [this message]
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=auMwIMerV-LQ-aNL@chamomile \
--to=pablo@netfilter.org \
--cc=coreteam@netfilter.org \
--cc=fw@strlen.de \
--cc=koral.ilgun@adtran.com \
--cc=koralilgun@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
/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