Ethernet Bridge development
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <razor@blackwall.org>
To: Petr Machata <petrm@nvidia.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org
Cc: Ido Schimmel <idosch@nvidia.com>,
	bridge@lists.linux.dev, mlxsw@nvidia.com,
	Denis Yulevych <denisyu@nvidia.com>,
	Amit Cohen <amcohen@nvidia.com>
Subject: Re: [PATCH net-next 1/2] net: bridge: Prevent unicast ARP/NS packets from being suppressed by bridge
Date: Wed, 9 Apr 2025 13:33:18 +0300	[thread overview]
Message-ID: <7d88da06-e943-4d78-a483-66d7ce151f00@blackwall.org> (raw)
In-Reply-To: <6bf745a149ddfe5e6be8da684a63aa574a326f8d.1744123493.git.petrm@nvidia.com>

On 4/8/25 18:40, Petr Machata wrote:
> From: Amit Cohen <amcohen@nvidia.com>
> 
> When Proxy ARP or ARP/ND suppression are enabled, ARP/NS packets can be
> handled by bridge in br_do_proxy_suppress_arp()/br_do_suppress_nd().
> For broadcast packets, they are replied by bridge, but later they are not
> flooded. Currently, unicast packets are replied by bridge when suppression
> is enabled, and they are also forwarded, which results two replicas of
> ARP reply/NA - one from the bridge and second from the target.
> 
> RFC 1122 describes use case for unicat ARP packets - "unicast poll" -
> actively poll the remote host by periodically sending a point-to-point ARP
> request to it, and delete the entry if no ARP reply is received from N
> successive polls.
> 
> The purpose of ARP/ND suppression is to reduce flooding in the broadcast
> domain. If a host is sending a unicast ARP/NS, then it means it already
> knows the address and the switches probably know it as well and there
> will not be any flooding.
> 
> In addition, the use case of unicast ARP/NS is to poll a specific host,
> so it does not make sense to have the switch answer on behalf of the host.
> 
> According to RFC 9161:
> "A PE SHOULD reply to broadcast/multicast address resolution messages,
> i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages.
> An ARP probe is an ARP Request constructed with an all-zero sender IP
> address that may be used by hosts for IPv4 Address Conflict Detection as
> specified in [RFC5227]. A PE SHOULD NOT reply to unicast address resolution
> requests (for instance, NUD NS messages)."
> 
> Forward such requests and prevent the bridge from replying to them.
> 
> Reported-by: Denis Yulevych <denisyu@nvidia.com>
> Signed-off-by: Amit Cohen <amcohen@nvidia.com>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Petr Machata <petrm@nvidia.com>
> ---
>  net/bridge/br_arp_nd_proxy.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/net/bridge/br_arp_nd_proxy.c b/net/bridge/br_arp_nd_proxy.c
> index 115a23054a58..1e2b51769eec 100644
> --- a/net/bridge/br_arp_nd_proxy.c
> +++ b/net/bridge/br_arp_nd_proxy.c
> @@ -160,6 +160,9 @@ void br_do_proxy_suppress_arp(struct sk_buff *skb, struct net_bridge *br,
>  	if (br_opt_get(br, BROPT_NEIGH_SUPPRESS_ENABLED)) {
>  		if (br_is_neigh_suppress_enabled(p, vid))
>  			return;
> +		if (is_unicast_ether_addr(eth_hdr(skb)->h_dest) &&
> +		    parp->ar_op == htons(ARPOP_REQUEST))
> +			return;
>  		if (parp->ar_op != htons(ARPOP_RREQUEST) &&
>  		    parp->ar_op != htons(ARPOP_RREPLY) &&
>  		    (ipv4_is_zeronet(sip) || sip == tip)) {
> @@ -410,6 +413,10 @@ void br_do_suppress_nd(struct sk_buff *skb, struct net_bridge *br,
>  	if (br_is_neigh_suppress_enabled(p, vid))
>  		return;
>  
> +	if (is_unicast_ether_addr(eth_hdr(skb)->h_dest) &&
> +	    msg->icmph.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION)
> +		return;
> +
>  	if (msg->icmph.icmp6_type == NDISC_NEIGHBOUR_ADVERTISEMENT &&
>  	    !msg->icmph.icmp6_solicited) {
>  		/* prevent flooding to neigh suppress ports */

Acked-by: Nikolay Aleksandrov <razor@blackwall.org>


  reply	other threads:[~2025-04-09 10:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 15:40 [PATCH net-next 0/2] bridge: Prevent unicast ARP/NS packets from being suppressed by bridge Petr Machata
2025-04-08 15:40 ` [PATCH net-next 1/2] net: " Petr Machata
2025-04-09 10:33   ` Nikolay Aleksandrov [this message]
2025-04-08 15:40 ` [PATCH net-next 2/2] selftests: test_bridge_neigh_suppress: Test unicast ARP/NS with suppression Petr Machata
2025-04-09 10:33   ` Nikolay Aleksandrov
2025-04-10  2:30 ` [PATCH net-next 0/2] bridge: Prevent unicast ARP/NS packets from being suppressed by bridge patchwork-bot+netdevbpf

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=7d88da06-e943-4d78-a483-66d7ce151f00@blackwall.org \
    --to=razor@blackwall.org \
    --cc=amcohen@nvidia.com \
    --cc=bridge@lists.linux.dev \
    --cc=davem@davemloft.net \
    --cc=denisyu@nvidia.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.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