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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.