Netdev List
 help / color / mirror / Atom feed
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
> 

      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