netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: David Ahern <dsahern@kernel.org>
Cc: Hangbin Liu <liuhangbin@gmail.com>,
	netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Thomas Haller <thaller@redhat.com>
Subject: Re: [PATCHv3 net] ipv6: do not match device when remove source route
Date: Tue, 25 Jul 2023 13:06:09 +0300	[thread overview]
Message-ID: <ZL+ekVftp24TzrHz@shredder> (raw)
In-Reply-To: <8c8ba9bd-875f-fe2c-caf1-6621f1ecbb92@kernel.org>

On Sun, Jul 23, 2023 at 12:12:00PM -0600, David Ahern wrote:
> On 7/23/23 2:13 AM, Ido Schimmel wrote:
> > 
> > I don't know, but when I checked the code and tested it I noticed that
> > the kernel doesn't care on which interface the address is configured.
> > Therefore, in order for deletion to be consistent with addition and with
> > IPv4, the preferred source address shouldn't be removed from routes in
> > the VRF table as long as the address is configured on one of the
> > interfaces in the VRF.
> > 
> 
> Deleting routes associated with device 2 when an address is deleted from
> device 1 is going to introduce as many problems as it solves. The VRF
> use case is one example.

This already happens in IPv4:

# ip link add name dummy1 up type dummy
# ip link add name dummy2 up type dummy
# ip address add 192.0.2.1/24 dev dummy1
# ip route add 198.51.100.0/24 dev dummy2 src 192.0.2.1
# 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 dummy2 scope link src 192.0.2.1 
# ip address del 192.0.2.1/24 dev dummy1
# ip -4 r s

IPv6 only removes the preferred source address from routes, but doesn't
delete them. The patch doesn't change that.

Another difference from IPv4 is that IPv6 only removes the preferred
source address from routes whose first nexthop device matches the device
from which the address was removed:

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

And this is despite the fact that the kernel only allowed the route to
be programmed because the preferred source address was present on
another interface in the same L3 domain / VRF:

# ip link add name dummy1 up type dummy
# ip link add name dummy2 up type dummy
# ip route add 2001:db8:2::/64 dev dummy2 src 2001:db8:1::1
Error: Invalid source address.

The intent of the patch (at least with the changes I proposed) is to
remove the preferred source address from routes in a VRF when the
address is no longer configured on any interface in the VRF.

Note that the above is true for addresses with a global scope. The
removal of a link-local address from a device should not affect other
devices. This restriction also applies when a route is added:

# ip link add name dummy1 up type dummy
# ip link add name dummy2 up type dummy
# ip -6 address add fe80::1/64 dev dummy1
# ip -6 route add 2001:db8:2::/64 dev dummy2 src fe80::1
Error: Invalid source address.
# ip -6 address add fe80::1/64 dev dummy2
# ip -6 route add 2001:db8:2::/64 dev dummy2 src fe80::1

  reply	other threads:[~2023-07-25 10:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-20  6:59 [PATCHv3 net] ipv6: do not match device when remove source route Hangbin Liu
2023-07-20 13:22 ` Ido Schimmel
2023-07-20 14:49   ` Ido Schimmel
2023-07-21  8:59     ` Hangbin Liu
2023-07-23  8:13       ` Ido Schimmel
2023-07-23 18:12         ` David Ahern
2023-07-25 10:06           ` Ido Schimmel [this message]
2023-07-25 22:37             ` David Ahern
2023-07-26  9:46               ` Hangbin Liu
2023-07-24  9:42         ` Hangbin Liu
2023-07-25  8:06           ` Ido Schimmel

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=ZL+ekVftp24TzrHz@shredder \
    --to=idosch@idosch.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=thaller@redhat.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;
as well as URLs for NNTP newsgroup(s).