Date: Thu, 20 Jul 2023 17:49:47 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
	David Ahern <dsahern@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Thomas Haller <thaller@...hat.com>
Subject: Re: [PATCHv3 net] ipv6: do not match device when remove source route

On Thu, Jul 20, 2023 at 04:22:11PM +0300, Ido Schimmel wrote:
> On Thu, Jul 20, 2023 at 02:59:41PM +0800, Hangbin Liu wrote:
> > After deleting an IPv6 address on an interface and cleaning up the
> > related preferred source entries, it is important to ensure that all
> > routes associated with the deleted address are properly cleared. The
> > current implementation of rt6_remove_prefsrc() only checks the preferred
> > source addresses bound to the current device. However, there may be
> > routes that are bound to other devices but still utilize the same
> > preferred source address.
> > 
> > To address this issue, it is necessary to also delete entries that are
> > bound to other interfaces but share the same source address with the
> > current device. Failure to delete these entries would leave routes that
> > are bound to the deleted address unclear. Here is an example reproducer
> > (I have omitted unrelated routes):
> 
> [...]
> 
> > Ido notified that there is a commit 5a56a0b3a45d ("net: Don't delete
> > routes in different VRFs") to not affect the route in different VRFs.
> > So let's remove the rt dev checking and add an table id checking.
> > Also remove the !rt-nh checking to clear the IPv6 routes that are using
> > a nexthop object. This would be consistent with IPv4.
> > 
> > A ipv6_del_addr test is added for fib_tests.sh. Note that instead
> > of removing the whole route for IPv4, IPv6 only remove the preferred
> > source address for source routing. So in the testing use
> > "grep -q src $src_ipv6_address" instead of "grep -q $dst_ipv6_subnet/64"
> > when checking if the source route deleted.
> > 
> > Here is the fib_tests.sh ipv6_del_addr test result.
> 
> [...]
> 
> > 
> > Reported-by: Thomas Haller <thaller@...hat.com>
> > Fixes: c3968a857a6b ("ipv6: RTA_PREFSRC support for ipv6 route source address selection")
> > Signed-off-by: Hangbin Liu <liuhangbin@...il.com>
> 
> Reviewed-by: Ido Schimmel <idosch@...dia.com>

Actually, there is another problem here. IPv4 checks that the address is
indeed gone (it can be assigned to more than one interface):

+ ip link add name dummy1 up type dummy
+ ip link add name dummy2 up type dummy
+ ip link add name dummy3 up type dummy
+ ip address add 192.0.2.1/24 dev dummy1
+ ip address add 192.0.2.1/24 dev dummy2
+ ip route add 198.51.100.0/24 dev dummy3 src 192.0.2.1
+ ip address del 192.0.2.1/24 dev dummy2
+ ip -4 r s
192.0.2.0/24 dev dummy1 proto kernel scope link src 192.0.2.1 
198.51.100.0/24 dev dummy3 scope link src 192.0.2.1 

But it doesn't happen for IPv6:

+ ip link add name dummy1 up type dummy
+ ip link add name dummy2 up type dummy
+ ip link add name dummy3 up type dummy
+ ip address add 2001:db8:1::1/64 dev dummy1
+ ip address add 2001:db8:1::1/64 dev dummy2
+ ip route add 2001:db8:2::/64 dev dummy3 src 2001:db8:1::1
+ ip address del 2001:db8:1::1/64 dev dummy2
+ ip -6 r s
2001:db8:1::/64 dev dummy1 proto kernel metric 256 pref medium
2001:db8:2::/64 dev dummy3 metric 1024 pref medium
fe80::/64 dev dummy1 proto kernel metric 256 pref medium
fe80::/64 dev dummy2 proto kernel metric 256 pref medium
fe80::/64 dev dummy3 proto kernel metric 256 pref medium

Powered by blists - more mailing lists