From: Ido Schimmel <idosch@nvidia.com>
To: Sagarika Sharma <sharmasagarika@google.com>
Cc: "David S . Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Shuah Khan <shuah@kernel.org>, Simon Horman <horms@kernel.org>,
Kuniyuki Iwashima <kuniyu@google.com>,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net v1 1/2] ipv6: update route serial number on NETDEV_CHANGE
Date: Tue, 28 Apr 2026 14:07:08 +0300 [thread overview]
Message-ID: <20260428110708.GA571865@shredder> (raw)
In-Reply-To: <20260427224243.3499162-2-sharmasagarika@google.com>
On Mon, Apr 27, 2026 at 10:42:22PM +0000, Sagarika Sharma wrote:
> When using IPv6 ECMP routes, if a netdev listed as a nexthop experiences
> a carrier change event (e.g., a bond device generating a NETDEV_CHANGE
> event after its slaves go linkdown), established connections utilizing
> that nexthop fail to fail over to other available nexthops. Instead,
> these connections stall or drop.
>
> This happens because the IPv6 FIB code does not invalidate the socket's
> cached destination when a NETDEV_CHANGE event occurs. While
> fib6_ifdown() correctly marks the nexthop with RTNH_F_LINKDOWN, it
> leaves the route's serial number unchanged. As a result, sockets with a
> previously cached dst do not realize the route is no longer viable and
> continue to try using the non-functional nexthop.
>
> This behavior contrasts with IPv4, which actively flushes cached
> destinations on a NETDEV_CHANGE event (see fib_netdev_event() in
> net/ipv4/fib_frontend.c).
>
> Fix this by updating the route serial number in fib6_ifdown() when
> setting RTNH_F_LINKDOWN. This invalidates stale cached destinations,
> forcing sockets to perform a new route lookup and fail over to a
> functioning nexthop.
>
> Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
> Signed-off-by: Sagarika Sharma <sharmasagarika@google.com>
> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
next prev parent reply other threads:[~2026-04-28 11:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 22:42 [PATCH net v1 0/2] ipv6: fix ECMP route failover on carrier loss Sagarika Sharma
2026-04-27 22:42 ` [PATCH net v1 1/2] ipv6: update route serial number on NETDEV_CHANGE Sagarika Sharma
2026-04-28 11:07 ` Ido Schimmel [this message]
2026-04-28 11:21 ` Eric Dumazet
2026-04-27 22:42 ` [PATCH net v1 2/2] selftest: net: Add test for TCP flow failover with ECMP routes Sagarika Sharma
2026-04-28 11:18 ` Ido Schimmel
2026-04-28 18:46 ` Kuniyuki Iwashima
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=20260428110708.GA571865@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sharmasagarika@google.com \
--cc=shuah@kernel.org \
/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.